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ABSTRACT 


This  thesis  defines  the  analysis  and  design  necessary  to  automate  the  current  manual 
procedures  for  the  inventor}',  requisitioning,  and  reporting  of  shipboard  ammunition. 
After  verifying  data  and  functional  requirements  of  the  system,  this  study  specifies  the 
logical  database  design  and  application  design  of  a  relational  shipboard  ammunition 
management  database  application.  In  addition,  the  PARADOX  relational  database 
management  system  software  package  is  used  to  implement  the  relations  and  specify  the 
required  reports  for  a  prototype  application.  The  potential  for  integrating  an  expert 
system  with  this  shipboard  ammunition  relational  database  is  discussed  and  other  areas 
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I.  INTRODUCTION 


A.  PURPOSE 

Operational  and  training  readiness  of  Navy  ships  depends  on  the  efficient  manage¬ 
ment  of  onboard  supplies.  Food,  fuel,  and  ammunition  inventories  must  be  effectively 
monitored  and  controlled.  Higher  command  authorities  have  recognized  the  critical  na¬ 
ture  of  these  inventories  by  mandating  reporting  procedures  to  ensure  the  proper  place¬ 
ment  of  these  vital  supplies.  Clearly,  the  ability  of  a  warship  to  go  quickly  into  combat 
is  determined  largely  by  the  supplies  carried  in  her  own  hull. 

The  vital  importance  of  efficient  shipboard  inventory  management  is  especially  ob¬ 
vious  in  the  area  of  conventional  ammunition  inventory,  requisitioning,  and  reporting. 
Ammunition  logistics  determines  a  ship's  possible  endurance  and  available  tactics.  In 
peacetime,  tracking  the  expenditure  and  replacement  of  shipboard  ordnance  is  especially 
important  because  of  its  impact  on  combat  systems  training  readiness.  A  ship  in  which 
operational  and  tactical  decision  makers  are  unaware  of  the  quantity  and  type  of  ord¬ 
nance  onboard  is  at  a  clear  disadvantage  in  peacetime  and  may  prove  to  be  a  dangerous 
liability  in  hostile  environments. 

Over  the  past  decade,  audits  of  shipboard  ammunition  management  procedures  have 
focused  attention  on  an  apparent  inability  to  maintain  accurate  ammunition  records. 
For  example,  two  General  Accounting  Office  (GAO)  investigations  (GAO,  1981  and 
1982)  found  significant  discrepancies  between  reported  quantities  and  assets  actually 
onboard.  The  Naval  Audit  Service  discovered  a  similar  finding  when  it  audited  small 
arms  and  ammunition  (NAS,  1981).  As  we  face  the  austere  defense  funding  levels  ex¬ 
pected  for  the  1990's,  Navy  managers  must  address  the  deficiencies  inherent  in  the  cur¬ 
rent  manual  system  of  shipboard  ammunition  management. 

The  present  (entirely  manual)  system  of  shipboard  ammunition  management  is 
manpower  intensive,  inefficient,  invites  errors,  and  provides  poor  information  support 
for  shipboard  managers.  The  requisitioning,  status  tracking,  expenditure  reporting,  and 
inventory  management  of  ammunition  inventories  to  comply  with  detailed  requirements 
of  higher  authority  imposes  a  significant  administrative  burden  on  Weapons  Department 
personnel.  An  automated  system  would  relieve  part  of  this  administrative  burden,  mak¬ 
ing  time  available  for  important  combat  systems  training.  In  addition,  an  automated 
system  would  make  accurate  ammunition  information  more  accessible  to  decision  mak- 
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ers  both  on  and  off  the  ship.  Unfortunately,  automated  tools  for  shipboard  ammunition 
management  do  not  exist,  either  as  part  of  the  Shipboard  Non-Tactical  ADP  (SNAP) 
system  installed  on  Navy  ships  or  as  a  stand-alone  microcomputer  application. 

The  purpose  of  this  thesis  is  to  provide  the  analysis  and  design  for  a  prototype  re¬ 
lational  database  application  intended  to  automate  the  manual  system  of  shipboard 
ammunition  inventory,  requisitioning,  and  reporting. 

B.  SCOPE 

1.  Scope  of  System 

This  thesis  defines  the  relational  database  design  of  the  proposed  Ammunition 
Requisition  Management,  Inventory,  and  Reporting  System  (ARM IRS),  a  single-user, 
microcomputer-based  database  application.  The  scope  of  ARM  IRS  is  limited  in  that  (1) 
the  current  system  defines  the  principal  functional  requirements  of  the  automated  sys¬ 
tem,  (2)  the  special  requirements  of  ammunition  stores  ships  afloat  and  naval  magazines 
ashore  are  not  addressed,  and  (3)  only  non-nuclear  ordnance  management  is  modeled. 

It  is  not  the  intent  of  this  research  to  specify  the  ideal  methods  for  shipboard 
ammunition  management  or  to  suggest  fundamentally  different  methods  of  ordnance 
inventory,  requisition,  or  reporting.  Rather,  ARMIRS  is  an  automated  application  of  a 
manual  system,  using  forms  and  reports  familiar  to  users  of  the  current  system. 

In  addition,  ARMIRS  will  not  meet  the  special  requirements  of  non-combatant 
ships.  A  single  ammunition  supply  ship  carries  ammunition  bound  for  many  combatant 
ships  and  has  especially  complex  requirements  for  ammunition  load  management. 

Finally,  ARMIRS  is  an  unclassified  system  for  unclassified  ordnance.  Nuclear 
weapons  management  has  distinct  managerial  and  security  requirements  beyond  the 
scope  of  this  system.  Because  of  the  comparatively  small  quantity  of  weapons  involved 
and  the  demanding  security  requirements,  inclusion  of  special  weapons  within  the  scope 
of  ARMIRS  is  not  required. 

2.  Scope  of  Thesis 

This  thesis  will  facilitate  future  development  of  a  prototype  ARMIRS  system 
by  defining  the  data  and  functional  requirements  of  the  system.  The  deliverable  product 
from  this  thesis  is  the  documentation  of  the  analysis  and  design  phases  of  systems  de¬ 
velopment.  A  high-level  conceptual  data  model  is  described.  This  conceptual  schema  is 
a  concise  description  of  the  user's  data  requirements  and  includes  detailed  descriptions 
of  the  data  types,  relationships,  and  constraints.  The  functional  requirements  of  a 
shipboard  ammunition  management  system  will  also  be  specified.  These  design  specifi- 
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cations  are  independent  of  any  particular  Database  Management  System  (DBMS).  The 
specifications  from  this  thesis  can  then  be  implemented  with  a  variety  of  DBMS  appli¬ 
cation  tools.  Data  model  mapping  into  the  data  model  of  PARADOX,!  a  relational 
microcomputer  DBMS  product  with  built-in  application  development  facilities,  is  used 
only  to  demonstrate  the  transformation  of  the  conceptual  schema  from  a  high-level  data 
model  to  an  implementation  data  model.  In  addition,  PARADOX  is  used  as  a  graphic 
interface  tool  to  specify  the  ARMIRS  reports.  However,  a  DBMS-specific,  working 
prototype  is  beyond  the  scope  of  this  thesis. 

C.  METHODOLOGY 

This  thesis  generally  follows  the  object-oriented  database  design  steps  outlined  by 
Kroenke  and  Dolan  (1988,  pp.  87-216)  and  by  Elmasri  and  Navanthe  (1989,  pp. 
453-483).  In  general,  these  steps  include: 

1.  Model  the  user's  view  of  the  data  as  objects. 

2.  Specify  the  application  and  its  functional  components  as  data  flows. 

3.  Define  the  relational  schema. 

4.  Design  the  control  and  display  features  of  the  application,  including  forms  and  re¬ 
ports. 

According  to  Kroenke  and  Dolan  (1988,  pp.  96-97),  there  are  two  methods  to  use 
in  identifying  and  describing  objects:  (1)  examine  the  application  outputs  and  work 
backwards  to  the  object  structure,  or  (2)  ask  the  user  to  describe  the  objects  and  model 
the  objects  from  their  characteristics  and  the  application.  The  first  methodology  is  useful 
when  an  improved  application  for  an  existing  system  is  required.  By  knowing  the  system 
output,  it  is  possible  to  determine  the  input.  The  second  method  is  required  for  new  ap¬ 
plications.  Because  there  are  no  reports  or  views  to  examine,  the  analysts  begin  by  ask¬ 
ing  users  to  describe  their  view  of  the  system  objects. 

The  former  methodology  is  appropriate  for  ARMIRS.  The  ARMIRS  requirements 
analysis  draws  from  the  previous  requirements  work  by  Alderman  (1986)  and  Smith 
(1987)  as  well  as  the  author's  own  shipboard  ammunition  management  experience.2  In 
addition,  interviews  with  Gunnery  Officers  and  Gunnery  Petty  Officers  aboard  four 

1  PARADOX  is  trademark  of  Borland  International. 

2  The  author  served  as  ASW  Officer  (13  months)  and  Weapons  Officer  (5  months)  aboard  a 
KXOX-class  frigate. 
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combatant  ships?  were  conducted  during  July  1989l  to  supplement  the  author's  expertise 
and  aid  in  modeling  the  user's  view  of  the  system. 

This  thesis  incorporates  the  dataflow  diagram  methodology  of  Yourdon  (1989)  into 
the  Kroenke  and  Dolan  framework.  The  techniques  developed  by  Hayes-Roth  (1985)  as 
applied  by  Kamel  and  Lekey  (1990)  are  used  to  define  a  rule-based  expert  system  that 
could  be  integrated  with  the  ARM  IRS  database  to  assist  in  Ammunition  Transaction 
Report  (ATR)  and  requisition  preparation. 

The  specific  tools  used  and  their  relationship  to  the  corresponding  design  steps  are 
discussed  in  the  context  of  thesis  organization.  This  organization  closely  parallels  the 
format  used  by  the  author  in  an  unpublished  work  (Buzzard,  et.  al,  1989)  using  the 
Kroenke  and  Dolan  framework. 

D.  PREVIOUS  WORK 

As  previously  discussed,  this  thesis  is  limited  to  the  analysis  and  design  phase  of  the 
database  application  system  life  cycle.  The  problem  of  this  phase,  as  stated  by  Eimasri 
and  Navanthe  (1989,  p.  457),  is  to  "design  the  logical  structure  of  one  or  more  databases 
to  accomodate  the  information  needs  of  the  users  in  an  organization  for  a  defined  set 
of  applications".  This  thesis  does  not  attempt  to  rewrite  the  existing  requirements  anal¬ 
ysis  of  Alderman  (19S6)  or  the  requirements  analysis  and  partial,  DBMS-specific  design 
by  Smith  (1987).  Instead,  this  thesis  is  a  continuation  of  these  previous  efforts  to  auto¬ 
mate  ammunition  management. 

Alderman's  (1986)  thesis  was  heavily  influenced  by  the  Navy's  Conventional  Am¬ 
munition  Integrated  Management  System  (CAIMS)  database.  The  data  dictionary  he 
presents  for  a  shipboard  system  is  copied  from  the  COBOL  description  of  data  elements 
in  the  CAIMS  system.  Alderman's  (19S6,  pp.  32-35)  file-based  system  is  also  outdated 
because  it  uses  separate  files  (and  forms)  for  sonobouys  and  for  explosive  ordnance. 
Sonobouys  previously  had  different  reporting  and  requisitioning  requirements.  Use  of  a 
file-based  approach  created  vnnecessary  complexity,  including  many  condition  flags. 
Because  Alderman  specified  custom-made  security  and  backup  components  in  the  sys¬ 
tem  rather  than  simply  adding  commercially  available  software  to  accomplish  these  sys¬ 
tem  management  functions,  additional  dataflow  diagrams  and  forms  were  necessary.  In 
addition,  because  a  query-by-forms  model  was  not  used,  the  review,  create,  and  update 
functions  were  each  accomplished  by  unique  forms.  Alderman  (1986,  p.  106-127)  used 

3  USS  MCCLUSKEY  (FFG-41).  USS  MARVIN  SHIELDS  (FF-1066),  USS  STEIN 
(FF- 1065),  and  USS  JOHN  YOUNG  (DD-973). 
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43  forms  to  define  the  system,  many  of  them  unnecessary  for  the  reasons  discussed 
above.  The  requirements  analysis  is  also  incomplete  in  that  important  functions  are  not 
described.  For  example,  the  internal  reports  generated  by  the  system  for  shipboard  use 
are  not  described  or  even  listed.  Alderman,  a  Supply  Corps  officer,  oriented  the  re¬ 
quirements  analysis  toward  a  Navy-wide  logistics  view  than  from  the  shipboard  user's 
view  of  the  system. 

Smith's  (19S7)  thesis  comes  closer  to  defining  the  user's  view  of  a  shipboard  am¬ 
munition  management  system.  An  analysis  of  the  current  manual  system  receives  some 
examination.  The  major  shortcoining  in  Smith's  work  is  the  attempt  to  begin  the  imple¬ 
mentation  (construction)  phase  before  completing  the  design  phase.  The  result  is  a  par¬ 
tial,  DBASE  IIH-specific  implementation  fragment.  Smith's  (1987,  p.  53)  chapter  on 
"design"  begins  with  a  physical  structure  description  of  the  DBASE  III  files  used.  As 
Whitten,  et.  ai,  (1986,  p.  158)  point  out,  the  design  specifications  should  be  fully  com¬ 
pleted  before  the  implementation  phase  begins.  We  should  avoid  the  temptation  to  pre¬ 
maturely  program  from  an  incomplete  design  or  we  risk  numerous  delays.  The  Smith 
(1987)  thesis  is  therefore  an  analysis  and  implementation  approach  to  the  shipboard 
ammunition  management  problem.  There  is  nothing  in  that  thesis  resembling  a  logic 
description  or  logic  specification  (pseudocode)  to  bridge  the  gap  between  analysis  and 
Smith's  DBASE  III  code.  For  this  thesis,  some  reverse  engineering  was  applied  to  some 
of  Smith's  (1987,  pp.  137-177)  DBASE  code  to  provide  another  user's  view.  Smith  (1987, 
p.  68)  only  implemented  the  requisition  functions  of  a  shipboard  ammunition  manage¬ 
ment  system.  Neither  Alderman  (1986)  nor  Smith  (1987)  used  objects  and  their  re¬ 
lationships  to  model  the  data. 

E.  ORGANIZATION 

This  chapter  has  discussed  the  need  for  automating  the  shipboard  ammunition 
management  process,  the  scope  of  both  the  proposed  ARM  IRS  database  application 
and  the  scope  of  this  thesis,  and  some  of  the  general  steps  and  tools  used  to  define  the 
ARM  IRS  design. 

The  next  chapter  describes  the  current  manual  system  for  shipboard  ammunition 
management.  The  manual  forms  and  reports  are  discussed  and  the  user's  view  of  the 
ordnance  management  process  is  analyzed. 5  The  problem  statement  is  further  defined. 

4  DBASE  III  is  a  trademark  of  Ashton-Tate. 

5  LT  Peter  C.  Lyle,  USNR  contributed  useful  comments  on  Chapter  II. 
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Chapter  III  updates  and  modifies  the  previously  discussed  prior  work  on  the  re¬ 
quirements  analysis  through  the  use  of  objects.  The  objects  are  identified  and  described 
using  object  diagrams  and  object  specifications.  The  functional  components  (update, 
display,  and  control  mechanisms)  of  ARM  IRS  are  defined.  Dataflow  diagrams  are  used 
to  describe  the  process. 

Chapter  IV  covers  the  transformation  of  the  objects  into  a  relational  diagram.  The 
menu-driven  control  mechanisms  are  defined  with  menu  hierarchy  diagrams.  Finally,  the 
logic  specifications  used  to  complete  each  menu  option  are  listed  in  a  Structured  English 
format. 

Chapter  V  describes  the  use  of  the  PARADOX  DBMS  package  to  demonstrate  the 
implementation  of  the  relations.  The  required  internal  and  external  reports  are  also  de¬ 
fined. 

The  final  chapter  briefly  investigates  a  possible  expert  system  interface  and  suggests 
other  future  work  on  automating  shipboard  ordnance  management. 


II.  THE  SHIPBOARD  AMMUNITION  MANAGEMENT  PROCESS 


The  purpose  of  this  chapter  is  to  review  the  current  manual  system  for  managing 
ammunition  aboard  Navy  ships.  Before  an  automated  system  can  be  designed,  we  need 
to  understand  the  functionality  of  the  current  system.  It  ir  then  possible  to  analyze 
problems  and  define  solutions.  This  chapter  first  examines  the  forms  and  reports  used 
in  ordnance  management.  These  forms  and  reports  form  the  basis  for  the  data  require¬ 
ments  discussed  in  the  chapter  that  follows.  The  interface  with  external  systems  is  ana¬ 
lyzed  and  a  typical  shipboard  ammunition  management  scenario  is  presented.  After 
defining  these  mission  requirements,  the  problems  with  the  current  manual  system  will 
be  discussed. 

A.  SHIPBOARD  FORMS  AND  REPORTS 
1.  Inventory  Records 

a.  Master  Stock  Record  Card 

The  heart  of  the  shipboard  ammunition  inventor}'  function  is  the  Ammuni¬ 
tion  Master  Stock  Record  Card  (XAVSUP  Form  1296).  One  record  card  is  maintained 
for  each  Navy  Ammunition  Logistics  Code  (NALC)  held  in  a  ship's  ammunition  inven¬ 
tory.  The  NALC  indicates  the  functional  type  of  ammunition.  Each  NALC  has  one  or 
more  associated  National  Item  Identification  Numbers  (NIIN).  The  N1IN  further  de¬ 
fines  the  specific  type  of  ammunition.  For  example,  one  NALC  identifies  12-gauge 
shotgun  shells  containing  size  00  shot.  Within  that  NALC,  one  particular  NIIN  is  for 
shells  with  a  paper  case  while  another  NIIN  refers  to  shells  with  a  plastic  case  (Smith, 
1987,  p.16). 

The  Master  Stock  Record  Cards,  filed  by  NALC  and  then  by  NIIN,  contain 
general  information  on  the  NIIN.  This  information  includes: 

•  Nomenclature  (Short  Title) 

•  Unit  of  Issue  (Packaging) 

•  Shipfill  or  Mission  Allowance 

•  Training  Allowance 

•  Supply  Cognizance  Symbol  (COG) 

•  Material  Control  Code  (MCC) 

•  Department  of  Transportation  Hazardous  Material  Code 
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•  Net  Explosive  Weight  (NHEEW) 

•  Coast  Guard  Hazardous  Material  Class 

•  Shipboard  Stowage  Location 

•  Remarks 

In  addition,  the  record  card  contains  a  history  of  transactions  effecting  the  status  or 
quantity  of  that  NUN.  Information  on  the  current  inventory  balance  is  obtained  from 
this  section  of  the  card.  The  card  is  organized  into  rows  for  up  to  16  transactions.  The 
column  headings  are: 

•  Entry  Date 

•  Document  Number  (Activity  +  Date  +  Serial  Number) 

•  Quantity  Received 

•  Quantity  Issued 

•  Expenditure  Type 

•  Expenditure  Quantity 

•  Quantity  On-Hand  (Serviceable) 

•  Quantity  On-Hand  (Unservicable) 

•  Ammunition  Transaction  Report  (ATR)  Serial  Number 

•  Unexpended  Training  Allowance 

•  Quantity  Due  In 

b.  LotjLocation  Card 

For  each  lot  number  (if  any)  within  a  NUN,  lot  card(s)  (NAVSUP  Form 
1297)  are  filed  behind  their  master  stock  cards.  Much  of  the  information  on  this  card  is 
copied  from  the  parent  master  card.  The  only  additional  information  in  the  NUN  de¬ 
scriptive  section  is  a  place  for  the  lot  number.  The  transactions  section  of  the  lot  card 
is  identical  in  format  to  the  corresponding  section  on  the  master  card  except  that  a  col¬ 
umn  for  consignee/consignor  is  added.  The  lot  card  is  used  to  record  transactions  for  a 
single  lot.  The  transactions  on  each  NIIN's  lot  cards  is  copied  from  the  NUN  master 
card.  There  is  no  information  on  the  lot  cards  (except  for  lot  number,  of  couise)  that  is 
not  also  contained  on  the  master  card. 

c.  Serial/  Location  Card 

Some  ordnance  items  are  designated  for  increased  tracking  by  assignment 
of  unique  serial  numbers.  For  example,  all  missiles,  all  torpedoes  and  some  mines 
(SPCCINST  S010.12D,  1988,  p.  8-4-7)  have  serial  numbers  while  gun  ammunition  does 
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not  have  an  identifier  for  a  single  round.  Items  that  require  Serial/Lot  Item  Tracking 
(SLIT)  have  one  or  more  Serial,  Location  Cards  (NAVSUP  Form  1356)  filed  behind  the 
master  card.  SLIT  controlled  items  may  be  serial  number  controlled  (one  or  more  serial 
cards  for  each  master  record  card)  or  serial  and  lot  controlled  {both  lot  cards  and  serial 
cards  for  a  single  master  record  card). 

The  serial  cards  contain  most  of  the  generic  NIIN  information  found  on  the 
master  card  (and  lot  cards).  The  transaction  section  has  three  additional  columns: 

•  Serial  Number  (each  card  has  space  for  17  serialized  items,  one  for  each  row) 

•  Maintenance  Due  Date 

•  Condition  (Servicable  or  Unservicable) 

Like  the  lot  cards,  the  serial  cards  duplicate  information  found  on  their  master  cards. 

2.  Requisition  Records 

The  goal  of  every  ship  is  to  maintain  all  of  their  ammunition  allowance  onboard 
or  on  order.  Ships  create  orders  for  ammunition  by  transmitting  requisitions.  In  general, 
these  ammunition  requisitions  contain  the  following  minimum  information: 

•  Document  Number 

•  Document  Identifier 

•  Requisition  Addressees 

•  Location  for  Receipt 

•  NALC 

•  NUN 

•  Nomenclature  (Short  Title)  [manual  requisitions  only] 

•  Quantity  Desired 

•  Unit  of  Issue 

•  COG  Symbol 

•  Project  Code 

•  Media  Status  Code 

•  Signal  Code 

•  Demand  Code 

•  Advice  Code 

•  Fund  Code 

•  Priority  Code 

•  Required  Delivery  Date 
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•  Remarks  [manual  and  naval  message  requisitions  only] 

•  Classification 

The  format  of  the  above  information  varies  with  the  type  of  requisition  used. 
A  ship  may  requisition  ammunition  using  three  different  requisition  formats: 

1.  Defense  Automatic  Addressing  System  (DAAS)  Message  Requisition.  These 
machine-read  messages  are  prepared  to  an  exact  format  specification  (see 
SPCCINST  8010. 12D,  1988,  pp.  8-2-6  to  8-2-16).  For  example,  these  requisitions 
cannot  contain  remarks,  are  limited  to  only  specified  addressees,  and  must  be  un¬ 
classified. 

2.  Naval  Message  Requisition.  Requisition,  excluded  from  submission  via  DAAS  are 
submitted  via  naval  message.  Requisitions  that  require  narrative  remarks  or  action 
addressees  other  than  DAAS  Dayton,  Ohio  are  in  this  format.  Like  the  DAAS 
requisitions,  these  requistions  are  transmitted  from  the  ship  via  the  Navy  telecom¬ 
munications  system. 

3.  Manual  Requisition.  The  DOD  Single  Line  Item  Manual  Requisition  Form  (DD 
Form  1348)  are  hand-carried  or  mailed  to  a  naval  magazine  or  weapons  station 
ashore.  The  requisition  information  is  then  entered  into  the  CALMS  system  from 
the  weapons  facility's  ADP  equipment.  DD  Form  1348  is  also  used  when  ships 
lurn-in  or  off-load  ammunition  to  shore  activities. 

In  addition  to  a  file  of  requisitions  (often  containing  all  three  formats)  and 
turn-in  documents,  the  ship  maintains  a  locally  prepared  Requisition  Log  and  Turn-In 
Log  or  a  combination  log  summarizing  both- requisitions  and  turn-ins.  The  requirement 
for  and  format  of  this  record  is  r  M  specified  by  higher  authority  but  is  recommended 
because  it  greatly  aids  the  assignment  of  document  numbers  and  tracking  of  outstanding 
requistions.  This  log  is  list  of  document  numbers  (the  identifier  for  requisitions  and 
turn-in  document)  usually  with  columns  for  NALC,  quantity,  short  title,  and  requisition 
status  remarks. 

3.  Transaction  Records 

a.  Ammunition  Transaction  Report 

Every  action  that  results  in  a  change  to  a  ship's  ammunition  inventor}'  (in¬ 
cluding  receipt,  issue,  transfer,  expenditure,  loss,  gain,  or  change  in  condition)  must  be 
reported  (within  48  hours)  in  a  prescribed  report  format  (SPCCINST  8010.12D,  1988, 
p.  8-4-3).  The  ATR  is  a  formatted  naval  message  containing  the  following  information: 

•  Classification 

•  Addressees 

•  Reference  (last  ATR  or  other  ATR  referenced  to) 

•  Unit  Identification  Code  (UIC)  of  reporting  unit 

1 
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•  UIC  of  training  allowance  allocation  command 

•  ATR  Serial  Number 

•  Julian  Date  of  Transaction 

•  Activity  Classification  Code  (ACC) 

•  NALC 

•  NIIN 

•  Condition  Code 

•  Beginning  Balance 

•  Serial  Number  (if  applicable) 

•  Lot  Number  (if  applicable) 

•  Source  UIC  (for  receipts) 

•  Source  Service  Code  (for  receipts) 

•  Expenditure  Transaction  Type 

•  Reclassification  Code 

•  Ending  Balance 

•  Remarks 

As  with  the  inventor}'  information,  ATR  format  varies  with  the  type  of 
control  (Material  Condition  Code)  applicable  to  that  type  of  ordnance.  The  individual 
transaction  lines  in  an  ATR  contain  information  that  varies  depending  on  whether  the 
item  is  non-SLIT,  SLIT  reportable  by  lot,  SLIT  reportable  by  serial,  or  SLIT  reportable 
by  serial  and  lot.  Another  highly  variable  item  on  an  ATR  is  the  list  of  action  and  in¬ 
formation  addressees  which  depends  both  on  the  location  of  the  unit  and  the  type  of 
ordnance  involved  in  the  reported  transaction. 

Each  ship  maintains  a  locally  prepared  ATR  Log  (often  in  addition  to  an 
ATR  file)  to  summarize  the  command's  ammunition  transaction  history  and  to  assist  in 
assigning  correct  ATR  serial  numbers.  As  with  requisitions,  it  is  essential  that  ATRs  are 
received  by  addressees  in  the  correct  sequence  with  no  unassigned  or  duplicated  serial 
numbers.  This  log  commonly  consists  of  rows  for  each  ATR  serial  number  with  columns 
for  message  date-time  group,  NALC(s),  type  of  transaction,  and  ending  balance. 
b.  Ammunition  Reclassification 

Ammunition  is  reclassified  when  external  inventor}’  or  technical  managers 
determine  that  a  particular  item  or  lot  should  be  used  in  a  limited  fashion  or  considered 
unserviceable.  This  reclassification  can  be  the  result  of  ammunition  malfunction,  tests, 
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shelf-life  expiration,  or  quality  evaluation  (NAVSEAINST  8015. 1A,  1988,  p.  XI-1).  If 
the  affected  ammunition  is  not  properly  marked  when  reclassified,  both  in  the  magazine 
and  on  the  inventor}'  record,  serious  personnel  injuries  or  weapons  systems  damage  can 
result.  In  addition,  mixing  serviceable  and  unserviceable  ammunition  aboard  ship  pre¬ 
sents  an  explosive  safety  hazard. 

Ships  periodically  receive  Notices  of  Ammunition  Reclassification  (NAR) 
messages  listing  ammunition  with  a  revised  condition  code.  These  serialized  messages 
are  then  checked  against  the  ship's  ordnance  holdings  to  determine  applicability.  If  the 
ship  holds  the  referenced  ammunition,  the  ordnance  is  tagged,  inventory  cards  are  up¬ 
dated,  an  ATR  is  transmitted  to  show  the  revised  condition  code,  and  action  is  taken 
depending  on  the  new  condition  code.  All  NAR  messages  are  filed  until  incorporated 
into  the  (approximately  annual)  revision  to  the  Naval  Sea  Systems  Command 
(NAVSEA)  publication  listing  all  Navy  ammunition  that  is  unserviceable,  suspended, 
or  of  limited  use  (NAVSEA  TWO24-AA-ORD10,  1989). 

B.  INTERFACE  WITH  EXTERNAL  SYSTEMS 

The  current  shipboard  ammunition  management  system  does  not  exist  in  isolation 
from  inventory  management  at  higher  levels.  The  forms  and  reports  discussed  above 
exist  not  only  to  assist  shipboard  decision  makers  in  managing  ordnance  inventories  but 
serve  to  keep  higher  eschelon  commanders  informed  of  ammunition  inventories  for  the 
squadron,  group,  and  fleet.  While  the  automation  boundary  of  the  proposed  ARM  IRS 
system  stops  at  the  brow  of  a  single  ship,  it  is  important  to  recognize  the  place  of 
shipboard  ammunition  management  in  the  larger  scheme  of  Navv-wide  logistics. 

The  Navy's  Conventional  Ammunition  Integrated  Management  System  (CAIMS) 
is  directed  by  the  Navy  Ship's  Parts  Control  Center  (SPCC)  at  Mechanicsburg, 
Pennsylvania.  CAIMS  is  an  integrated  management  information  system  using  large  scale 
automatic  data  processing  equipment  designed  to  provide  daily  updates  of  ammunition 
inventories  to  Fleet-level  and  Navy  Department  commanders  (OPNAVINST  8000.13, 
1971,  p.  3).  It  is  therefore  the  Navy's  central  repository  of  ammunition  inventory  infor¬ 
mation.  However,  CAIMS  is  more  than  just  an  inventory  tool.  It  is  also  used  for  read¬ 
iness  assessment,  operational  decision  making,  technical  evaluation,  procurement 
planning,  and  budget  determination  (Swanson,  1977,  p.  23).  The  ATRs  submitted  to 
SPCC  form  the  interface  between  the  ship  and  the  central  CAIMS  database.  SPCC 
provides  information  to  ships  in  the  form  of  quarterly  reconciliation  reports.  These  re¬ 
ports  reflect  data  on  selected  items  from  the  ship's  inventory  according  to  the  CAIMS 
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database.  The  reconciliation  report  is  compared  to  the  (manual)  inventor)'  records  and 
CAIMS  is  updated  with  an  ATR  from  the  ship.  SPCC  also  provides  feedback  to  ships 
on  erroneous  ATRs.  For  example,  a  ship  is  notified  by  naval  message  if  there  is  a 
missing  ATR  or  if  an  ATR  serial  number  out  of  sequence. 

The  Naval  Ordnance  Management  Information  System  (NOM1S)  is  installed  at 
major  ordnance  facilities  ashore.6  The  NOMIS  stock  records  are  the  official  inventory 
records  of  the  weapons  station.  This  system  provides  information  support  for  the  receipt, 
storage,  segregation,  issue,  and  movement  of  conventional  ammunition  ashore 
(NAVSEA1NST  S015.1A,  1988,  p.  2).  ATRs  from  shore  installations  are  transmitted  to 
CAIMS  via  AUTODIN.  Just  as  in  the  ship-to-CAIMS  interface,  accurate  and  timely 
transaction  reporting  is  the  cornerstone  of  CAIMS  accuracy.  The  interface  between 
NOMIS  and  the  fleet  is  through  the  requisitions  and  turn-in  documents  generated 
onboard. 

C.  PROCESS  SCENARIO 

The  following  sample  transaction  history6 7 8  (adapted  from  SPCCINST  8010. 12D, 
1988,  p.  12-1  -B 1)  illustrates  how  the  forms,  reports,  logs,  and  files  discussed  above  are 
used  together  in  a  typical  shipboard  ammunition  management  situation.?  While  this 
scenario  does  not  fully  describe  the  information  flow  and  requirements  of  ARM  IRS,  it 
does  help  illustrate  characteristics  of  the  current  manual  system  and  aids  in  defining  the 
problems  with  the  status  quo. 

1.  (900210)  Opened  new  master  stock  record  card  with  quantities  carried  over  from 
previous  records.  Posted  746  to  ONHAND  BALANCES  (CONDITION  CODE 
"A")  and  150  to  UNEXPENDED  TRAINING  ALLOCATIONS  Itemize  the 
master  card  quantity  by  lots  and  copy  the  information  to  the  new  lot  cards. 

2.  (900312)  Fired  63  rounds  in  a  gunnery  exercise.  Post  63  to  Transaction  Type  "F". 
Update  the  balance  to  show  683  in  Condition  Code  "A".  Reduce  UNEXPENDED 
TRAINING  ALLOCATION  to  87.  Use  the  ATR  Log  to  locate  the  next  ATR  se¬ 
rial  number.  Post  the  ATR  serial  number  to  the  master  card.  Copy  information  to 
the  lot  cards.  Draft  an  ATR  message  and  file  a  copy. 


6  WPNSTA  Charleston.  WPNSTA  Concord,  WPNSTA  Earle,  WPNSTA  Seal  Beach, 
WPNSTA  Yorktown,  NAVORDSTA  Indian  Head,  and  NAVUSEAWARENGSTA  Keyport. 

7  The  scenario  is  for  5-inch  gun  projectiles  aboard  a  destroyer. 

8  Note  that  UNEXPENDED  TRAINING  ALLOWANCE  is  on  a  fiscal  year  basis  and  is 
reduced  any  time  a  training,  test,  or  operations  expenditure  in  posted.  A  balance  cannot  be  carried 
over  to  a  new  fiscal  year.  The  amount  of  the  authorized  Training  Allowance  (formally  known  as 
the  Non-Combat  Expenditure  Allowance,  or  NCEA)  is  entered  on  01  October  of  each  year. 
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3.  (900313)  Requisition  63  rounds  to  replace  the  ammunition  used  in  yesterday's 
gunnery  exercise.  Use  the  requisition  log  to  ensure  that  the  next  requisition  serial 
number  is  used.  Post  requisition  R540665072S009  to  DOCUMENT  NUMBER  and 
post  63  rounds  to  QUANTITY  DUE  IN. 

4.  (900325)  Fired  12  rounds  for  test.  Post  12  to  Transactions,  Type  "G".  Reduce 
ONHAND  Condition  "A"  to  671  and  UNEXPENDED  TRAINING  ALLO¬ 
CATION  to  75.  Prepare  the  next  ATR  message  and  post  the  report  serial  number 
to  the  ATR  block  on  the  master  card.  Update  the  quantity  on  the  lot  card. 

5.  (900429)  Received  the  63  rounds  ordered  last  month.  Post  R540660072S009  to 
DOCUMENT  NUMBER  and  Transaction  Type  C.  Increase  Condition  Code  "A" 
amount  to  734.  Reduce  QUANTITY  DUE  IN  to  0.  Update  the  Requisition  Log. 
If  these  new  rounds  are  from  a  different  lot,  create  a  new  lot  card  and  transfer  the 
information  from  the  master  card.  Prepare  an  ATR  and  update  the  ATR  Log. 

6.  (900515)  Receive  a  Notice  of  Ammunition  Reclassification  (NAR)  regarding  the 
suspension  of  one  lot.  Post  quantity  21  to  Transaction  Type  "X".  Reduce  Condition 
Code  "A"  to  713  and  open  a  balance  of  21  in  Condition  Code  "J".  Prepare  an  ATR 
to  report  the  change  in  Condition  Code. 

7.  (900604)  Fired  32  rounds  in  another  gunnery  exercise.  Posted  32  to  Transaction 
Type  "F".  Reduce  Condition  Code  "A"  to  681.  Reduce  UNEXPENDED  TRAIN¬ 
ING  ALLOWANCE  TO  43.  Prepare  ATR  message  and  post  the  report  serial 
number  to  the  ATR  block  on  the  master  card.  Update  the  lot  card. 

8.  (900704)  Receive  a  NAR  regarding  the  lot  in  Condition  Code  "J".  The  lot  is  de¬ 
clared  unserviceable.  Post  21  rounds  to  Transaction  Type  "X"  and  Condition  Code 
"H".  Reduce  Condition  Code  "J"  by  21.  Prepare  an  ATR  to  show  the  change  in 
Condition  Code. 

9.  (900S06)  Offload  the  21  unserviceable  rounds  at  Naval  Magazine  Lualualei,  HI. 
Prepare  a  DD  Form  134S  turn-in  document  and  enter  the  document  number  on  the 
master  card  and  in  the  Turn-In  Log.  Adjust  the  quantities  on  the  inventory  card, 
decreasing  Condition  Code  "H"  by  21.  Prepare  an  ATR  to  report  the  transfer. 

D.  PROBLEM  DEFINITION 

The  preceding  overview  of  the  current  manual  system  for  shipboard  ammunition 
management  helps  define  some  of  the  problems  with  the  exisiting  system: 

•  The  system  is  inefficient  because  it  often  requires  the  same  information  to  be  writ¬ 
ten  more  than  once  (e.g.,  copy  data  from  master  cards  to  lot  or  serial  cards). 

•  Filing  of  inventory'  cards  only  by  NALC  and  NIIN  limits  the  flexibility  and  value 
of  the  system.  Sorting  and  displaying  ammunition  inventor}'  information  by  other 
attributes  would  require  annotating  and  refiling  each  card. 

•  Extracting  information  from  many  inventory  cards,  logs,  files,  and  publications  is 
time  consuming. 

•  There  are  no  reliable  and  easily  accessed  indicators  of  undesirable  situations  (e.g., 
expired  maintenance  due  dates,  low  stock  levels,  or  low  training  allowance  bal¬ 
ances). 
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•  Working  with  the  current  system  is  highly  repetitive  and  can  be  especially  frus¬ 
trating  for  inexperienced  personnel. 

•  The  error-prone  manual  ammunition  management  system  undermines  the  reliabil¬ 
ity  of  the  Navy- wide  CAIMS  database  which  depends  on  accurate  and  timely 
transaction  reports. 

•  The  manual  preparation  of  complex  and  time-consuming  forms  and  reports  (espe¬ 
cially  ammunition  transaction  reports  and  requisitions)  is  an  inefficient  use  of  per¬ 
sonnel. 

This  chapter  has  defined  the  data  and  processes  involved  in  the  current  manual 
system  of  afloat  ordnance  management.  An  analysis  of  these  forms,  reports,  and  proce¬ 
dures  helps  define  the  problem  domain.  In  the  next  chapter,  an  information  model  is 
used  to  describe  the  vocabulary  and  conceptualization  of  this  problem  domain. 


III.  REQUIREMENTS  VERIFICATION 


The  previous  chapter  defined  the  problem  domain  for  shipboard  ammunition  man¬ 
agement.  This  chapter  is  concerned  with  building  a  model  of  the  information  in  that 
domain.  This  information  model  identifies  and  abstracts  what  is  in  the  problem.  Similar 
"things"  in  the  problem  are  identified  and  abstracted  as  objects  We  will  see  how  this 
process  of  object  definition  helps  formalize  knowledge  about  ordnance  management  on 
U.S.  Navy  ships.  After  the  objects  are  defined,  a  model  of  the  system's  data  (i.e.,  object) 
flows  is  constructed  to  aid  application  analysis. 

A.  DATA  REQUIREMENTS 

1.  Object  Overview  -  Modeling  the  User's  View 

An  object,  as  defined  by  Shlaer  and  Mellor  (1988,  p.  14),  is  an  abstraction  of  a 
set  of  real-world  things  such  that  (1)  all  of  the  real-world  things  in  the  set  (the  instances) 
have  the  same  characteristics,  and  (2)  all  instances  are  subject  to  and  conform  to  the 
same  rules.  These  two  characteristics  help  define  objects  that  allow  simple  operations 
on  the  data  that  are  easy  to  understand  and  easy  to  get  right. 

Identifying  the  objects  in  shipboard  ammunition  management  is  straightfor¬ 
ward.  We  start  by  asking.  "What  are  the  things  in  the  ordnance  inventory,  requisitioning, 
and  reporting  problem?"  These  ammunition-related  things  fall  into  two  broad  categories: 
(1)  tangible  things,  and  (2)  incidents  or  interactions. 

Tangible  things  are  the  easiest  objects  to  find.  Given  the  problem  discussion  in 
the  last  chapter,  we  clearly  have  ammunition  as  a  tangible  object.  But  we  have  different 
requirements  for  capturing  information  on  this  ammunition.  Is  it  ammunition  we  have 
onboard  (AMMO  INVENTORY  object)  or  ammunition  we  want  to  obtain  (REQUI¬ 
SITION  and  LINE  ITEM  objects)?  It  is  also  important  how  this  ammunition  is  con¬ 
trolled  and  accounted  for.  Some  ammunition  is  uniquely  identified  by  the  serial  number 
on  an  individual  piece  of  ordnance.  Other  rounds  are  identified  by  just  a  lot  number. 
Requirements  also  exist  to  identify  some  ammunition  by  both  serial  and  lot  number. 
Some  ammunition  has  neither  lot  numbers  nor  serial  numbers.  These  different  views  of 
the  problem  require  different  objects.  In  addition,  we  need  to  capture  information  about 
our  ship  and  about  the  ship  or  weapons  station  participating  in  our  ammunition  trans¬ 
actions  (COMMAND  object).  From  our  knowledge  of  the  tangible  things  involved  in 
ammunition  management,  the  following  objects  are  easy  to  identify: 
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•  COMMAND 

•  REQUISITION 

•  REQN  LINE  ITEM 

•  AMMO  INVENTORY 

•  LOT  CONTROLLED  AMMO 

•  SERIAL  CONTROLLED  AMMO 

•  SERIAL  &  LOT  CONTROLLED  AMMO 

Incident  or  interaction  objects  represent  an  event  (something  which  happens  at 
a  specific  time)  or  have  a  "transaction"  quality  (relating  to  two  or  more  other  objects  in 
our  model).  Incidents  (like  expending  ammunition  during  a  gunnery  exercise)  or  trans¬ 
actions  (like  receiving  requisitioned  torpedoes  from  the  naval  weapons  station)  result  in 
changes  to  a  ship's  ammunition  inventory’.  Information  about  these  changes  is  captured 
in  the  TRANSACTION  object. 

Object  diagrams,  like  those  in  Appendix  A,  are  pictures  of  the  user's  perception 
of  an  object  in  the  work  environment.  These  objects  diagrams  help  to  summarize 
knowledge  of  an  object  and  to  present  it  visually  and  unabiguously.  The  diagrams  in 
Appendix  A  follow  the  object  diagram  conventions  of  Kroenke  and  Dolan  (1988,  pp. 
91-97).  The  eight  objects  in  the  ARMIRS  database  are  represented  as  eight  boxes.  Inside 
each  box  is  a  list  of  all  properties  of  that  object.  Some  of  the  properties  are  written  in 
lowercase  letters,  while  others  appear  in  uppercase  letters  and  are  enclosed  in  boxes 
themselves.  Some  of  these  properties  have  the  letters  MV  next  to  them.  The  paragraphs 
that  follow  examine  the  object  diagrams  in  Appendix  A  while  discussing  the  object 
properties. 

2.  Object  Descriptions 

a.  COMMAND  Object 

The  COMMAND  object  (Figure  1)  includes  ten  properties.  Each  property 
represents  an  important  characteristic  of  the  ship  or  shore  activity  involved  in  an  am¬ 
munition  transaction,  such  as  the  unit  identification  code  (UIC),  the  ship  or  station 
name  (Name),  and  descriptive  information  about  the  ammunition  in  the  command's  in¬ 
ventory  (AMMO  INVENTORY  -  MV).  The  first  eight  properties  listed  (see  Appendix 
A)  are  non-object  properties.  The  last  two,  which  are  capitalized  and  enclosed  in  boxes, 
are  object  properties.  An  object  property  is  a  characteristic  of  the  entity  that  is  actually 
another  object  (Kroenke  and  Dolan,  1988.  p.  91).  As  a  result,  there  are  other  object  di¬ 
agrams  for  REQUISITION  and  AMMO  INVENTORY.  The  REQUISITION  object 

t 


17 


will  contain  properties  of  the  ammunition  requisitions  sent  by  a  ship  and  the  AMMO 
INVENTORY  object  will  contain  properties  of  the  ordnance  held  onboard.  This  is  an 
example  of  one  object  "containing"  other  objects.  Since  a  command  instance  is  uniquely 
identified  by  a  U1C,  this  object  identifier  is  distinguished  from  the  other  properties  by 
an  asterisk  in  the  object  diagrams. 

The  COMMAND  object  includes  properties  that  are  allowed  to  have  a 
single  value  while  others  are  allowed  to  have  multiple  values.  For  example,  a  command 
instance  is  allowed  to  have  only  one  value  for  UIC.  However,  AMMO  INVENTORY 
and  REQUISITION  are  allowed  multiple  values  (indicated  by  the  letters  MV)  because 
a  command  holds  many  inventory  items  (the  instances  represented  by  the  Master  Stock 
Record  cards)  and  many  requisitions  (each  instance  is  an  entry  in  the  command's  Req¬ 
uisition  Log  or  File).9 

b.  REQUISITION  Object 

The  REQUISITON  object  (Figure  1)  contains  general  information  about 
ammunition  requisitions  sent  from  one  command  and  filled  by  another.  This  object  does 
not  contain  desired  NIINs  or  quantities.  That  information  is  found  in  REQN  LINE 
ITEM.  The  instance  of  the  REQUISITION  object  is  a  single  requisition  header  (either 
DAAS,  naval  message,  or  DD  Form  134S)  uniquely  identified  by  a  document  number. 
A  requisition  contains  one  or  more  line  items  (described  in  detail  in  the  REQN  LINE 
ITEM  object)  for  each  type  of  ammunition  desired.  A  requisition  also  includes  a  docu¬ 
ment  identifier  and  security  classification  and  may  contain  remarks  (depending  on  the 
requisition  format  chosen).  The  requisition  is  addressed  to  multiple  action  or  informa¬ 
tion  addressees  in  accordance  with  fleet  instructions  and  depending  on  the  type  of  ord¬ 
nance  desired. 

c.  REQN  LINE  ITEM  Object 

The  information  in  this  object  (Figure  2),  found  at  least  once  in  ever)'  req¬ 
uisition,  is  represented  by  a  single  line  on  an  ammunition  requisition.  A  separate  line  is 
used  for  each  NIIN.  For  example,  on  a  single  requisition  for  Harpoon  missiles,  shotgun 
rounds,  and  signal  flares,  we  would  find  three  different  line  items.  Each  line  item  contains 
information  on  the  quantity  desired  as  well  as  the  desired  delivery  date.  A  requisition  line 
may  have  a  classification  different  (but  not  higher)  than  the  entire  requisition.  Since  a 

9  As  Kroenke  and  Dolan  (1988,  p.  94)  point  out,  whether  a  property  is  single  or  multiple¬ 
valued  has  nothing  to  do  with  whether  it  is  an  object  or  non-object  property.  Note  that  the 
COMMAND  object  happens  to  contain  single-valued,  non-object  properties  and  multi-valued, 
object  properties  only  by  coincidence. 
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line  item  is  associated  with  only  one  requisition,  the  REQUISITION  object  is  a  single¬ 
value,  object  property  of  this  object.  (Obviously  a  line  item  does  not  exist  alone  without 
a  requisition  header.)  A  line  item  instance  may  be  associated  with  one  Master  Stock 
Record  Card  so  that  many  of  the  properties  of  INVENTORY  (i.e.,  unit  of  issue  and 
COG  symbol)  are  "contained"  in  the  REQN  LINE  ITEM  object  and  found  on  ammu¬ 
nition  requisitions. 

d.  AMMO  INVENTOR  Y  Object 

An  instance  of  the  AMMO  INVENTORY  object  (Figure  3)  is  the  descrip¬ 
tive  header  on  a  single  Master  Stock  Record  Card.  With  instances  uniquely  identified 
by  NIIN,  this  object  captures  information  on  ammunition  held  by  a  command  (i.e.,  al¬ 
lowance,  shipboard  location(s),  and  COG  symbol).  The  history  of  inventory  balance 
changes  for  that  NUN  is  captured  in  the  TRANSACTION  object  discussed  below.  The 
AMMO  INVENTORY  object  also  contains  the  total  quantity  on  hand  as  posted  from 
ammunition  transactions.  Associated  with  an  AMMO  INVENTORY*  instance  may  be 
one  01  more  lot  controlled,  serial  controlled,  or  serial  and  lot  controlled  objects.  REQN 
LINE  ITEM  is  also  a  multi-value,  object  property  of  AMMO  INVENTORY. 

e.  LO  T  CONTROLLED  AMMO  Object 

Lot  controlled  ammunition  (Figure  4)  is  uniquely  identified  by  lot  number 
and  has  one  or  more  shipboard  stowage  locations.  AMMO  INVENTORY*  is  a  single¬ 
value,  object  property  here  because  of  the  one-to-many  relationship  between  the  Master 
Stock  Record  Card  (AMMO  INVENTORY  properties)  and  the  Lot, 'Location  Card(s) 
(LOT  CONTROLLED  AMMO  properties).  TRANSACTION  is  a  multi-value  object 
property  since  one  ammunition  lot  has  one  or  more  transactions. 
f  SERIAL  CONTROLLED  AMMO  Object 

The  serial  number  is  the  object  identifier  for  this  object  (Figure  4).  The 
non-key  attributes  include  maintenance  due  date,  type  of  maintenance  due  code,  and  a 
stowage  location.  As  with  the  LOT  CONTROLLED  AMMO  object,  AMMO  INVEN¬ 
TORY*  is  a  single-value,  object  property  here.  In  addition,  the  TRANSACTION  object 
is  a  property  of  SERIAL  CONTROLLED  ammunition.  One  serial  number  has  one  or 
more  associated  transactions. 

g.  SERIAL  &  LOT  CONTROLLED  AMMO  Object 

This  object  includes  all  of  the  properties  found  in  the  previous  object  with 
the  addition  of  the  lot  number. 
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h.  TRANSACTION  Object 

A  TRANSACTION  instance  is  represented  by  one  of  the  lines  on  the  bal¬ 
ance  history  section  of  a  Master  Stock  Record  Card.  This  object  (Figure  5)  therefore 
includes  AMMO  INVENTORY  as  a  single-value,  object  property.  Every  balance 
change  is  uniquely  identified  by  a  single  line  on  a  serially  numbered  ATR.  Every  ATR 
has  multiple  addressees.  Single-value,  non-object  properties  of  this  object  include  the 
transaction  date,  the  old  balance,  the  quantity  issued/received/expended,  and  updated 
condition  code.  Since  a  TRANSACTION  can  involve  any  of  the  three  ammunition 
control  categories  discussed  above  (or  none  of  them  for  non-SLIT  transactions),  a  di¬ 
agonal  line  in  the  corner  of  these  object  boxes  indicates  that  only  one  (or  none)  of  these 
object  properties  may  apply  in  a  TRANSACTION  instance. 

3.  Object  Specifications 

Appendix  B  presents  the  complete  object  specifications  for  ARM  IRS.  The  ap¬ 
pendix  consists  of  two  parts:  (1)  object  definitions,  and  (2)  domain  definitions.  Object 
definitions,  as  used  by  Kroenke  and  Dolan  (198S,  p.  108),  list  all  the  properties  of  an 
object  and  indicate  the  domain  from  which  values  for  each  property  can  be  drawn.  The 
domain  definitions  specify  formats,  lengths,  and  special  restrictions  on  the  values  of  each 
domain.  Note  that  the  domain  definitions  are  separate  from  the  object  definitions.  This 
helps  reduce  duplicate  domain  definitions  because  one  domain  may  be  used  for  multiple 
properties.  For  example,  the  same  domain  (Navy  command  names)  can  be  used  for  both 
COM M AND.Names  and  REQUlSITION.Addressees. 

The  object  specifications  in  Appendix  B  are  detailed  enough  to  be  used  for  the 
next  phase-database  design. 

a.  Object  Definitions 

The  object  specification  syntax  used  by  Kroenke  and  Dolan  (1988,  pp. 
108-1 10)  is  used  is  this  work.  The  first  part  of  Appendix  B  includes  the  object  definitions. 
All  of  the  properties  of  an  object  are  listed.  A  semicolon  separates  the  name  of  each 
property  from  its  domain.  If  the  domain  is  another  object  but  only  some  of  the  proper¬ 
ties  are  carried  over  to  the  object  being  defined,  then  the  word  SUBSET  is  used  and  the 
properties  of  the  foreign  object  are  enclosed  in  brackets.  For  example,  COMMAND  is 
a  foreign  object  in  AMMO  INVENTORY,  with  only  the  properties  UIC,  Name,  and 
Hull  Number  applicable  to  the  user's  view  of  COMMAND  data  in  AMMO  INVEN¬ 
TORY. 
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b.  Domain  Definitions 

The  second  part  of  Appendix  B  contains  the  domain  definitions  which  de¬ 
scribe  the  set  of  values  from  which  an  instance  of  a  property  may  be  drawn.  These  do¬ 
main  definitions  also  follow  the  Kroenke  and  Dolan  (1988,  p.  110)  syntax.  They  include 
both  physical  and  semantic  descriptions.  The  physical  description  may  contain  a  mask-a 
restriction  on  the  allowable  values.  For  example,  "Fund  codes"  is  a  domain  whose  de¬ 
scription  includes  a  mask  specifying  that  the  first  digit  must  be  a  letter  and  that  the  last 
digit  must  be  the  number  six.  In  the  physical  descriptions,  "numeric"  means  the  digits  0 
through  9,  "alphabetic"  means  the  letters  A  thorough  Z,  and  "text"  includes  letters, 
numbers,  and  symbols. 

B.  APPLICATION  (FUNCTIONAL)  REQUIREMENTS 
1.  Dataflow  Diagrams 

One  widely  used  tool  for  studying  business  functions  is  the  dataflow  diagram. 
Dataflow  diagrams  (DFDs)  help  determine  how  the  organization  creates,  edits,  deletes, 
and  displays  objects.  DFDs  also  serve  as  a  clear  and  convenient  communication  tool  for 
users  and  analysts.  Even  in  situations  where  automation  is  not  of  interest,  DFDs  are 
used  for  problem  analysis.  For  example,  this  tool  has  been  used  to  document  and  ana¬ 
lyze  physical  product  flows  in  manufacturing  firms  as  well  as  information  flows  in  service 
organizations  (Kuehn  and  Fleck,  1990,  p.  10). 

As  Yourdon  (1989,  p.  140)  pointed  out,  DFDs  are  particularly  valuable  for  op¬ 
erational  systems  in  which  the  functions  of  the  system  are  of  paramount  importance  and 
more  complex  than  the  data  that  the  system  manipulates.  The  DFD  is  just  one  of  the 
modeling  tools  available  to  study  the  shipboard  ammunition  management  process.  It 
provides  only  one  view— the  functional  view.  The  DFD  is  a  useful  tool  in  AR.Y1IRS 
systems  analysis  because  it  aids  in  representing  the  key  functions  of  the  current  manual 
system  and  helps  identify  the  flow  of  data  and  the  actions  on  objects. 

This  thesis  uses  the  popular  "Yourdon  and  DeMarco  Methodology"  for  DFDs 
and  follows  the  conventions  used  in  Yourdon's  (1989,  pp.  139-187)  classic  work.  The 
diagrams  in  Appendix  C  illustrate  the  use  of  typical  Yourdon-style  components  in  a  se¬ 
ries  of  leveled  diagrams.  These  components  include  the  process,  the  flow,  the  store,  and 
the  terminator. 

The  first  component  of  the  DFD  is  known  as  the  process,  represented  graph¬ 
ically  by  a  circle.  The  process  is  named  with  a  verb-object  phrase  that  describes  what  the 
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process  does  such  as  GENERATE  REQUISITIONS,  MANAGE  INVENTORY,  or 
GENERATE  REPORTS. 

The  flow  is  represented  graphically  by  an  arrow  in  or  out  of  the  process.  The 
flow  describes  the  movement  of  data  packets  from  one  part  of  the  system  to  another. 
As  shown  in  the  diagrams  in  Appendix  C,  the  packets  carried  by  these  flows  could  be 
physical  objects  such  as  ONLOADED  AMMO.  Flows  can  be  split  into  several  more 
elementary  data  packets.  For  example,  the  dataflow  ALLOWANCE  in  Figures  6  and  7 
is  split  in  Figure  8  into  MISSION  ALLOW,  NCE  ALLOW,  and  SHIPFILL  ALLOW. 

The  store  models  a  collection  of  data  packets  at  rest.  The  notation  for  the  store 
is  two  parallel  lines.  A  store  might  consist  of  ammunition  stock  records  in  a  card  file  or 
ammunition  requisitions  in  a  file  folder.  Figure  7  shows  the  five  stores  in  the  manual 
ammunition  management  system. 

The  context  DFD  (Figure  6)  shows  the  terminators  (sources  and  sinks)  in  the 
system;  they  are  graphically  represented  by  a  rectangle.  Terminators  are  the  external 
entities  with  which  the  system  communicates  These  entities  (like  "User"  in  Figure  6)  may 
be  internal  to  the  organization  but  outside  the  control  of  the  system  being  modeled.  In 
the  ammunition  management  environment,  these  terminators  include  the  shipboard  user, 
the  weapons  station  or  other  ship,  DAAS,  SPCC,  and  NAVSEA. 

The  ARMIRS  bubbles  (processes)  are  numbered  according  to  Yourdon's  (1989, 
pp.  165-171)  hierarchical  system  of  leveled  diagrams.  Figure  6  consists  of  only  one  bub¬ 
ble  (Process  0)  representing  the  entire  system;  the  dataflows  show  the  interfaces  between 
the  shipboard  ammunition  management  process  and  the  external  terminators.  As  shown 
by  Figure  7,  the  DFD  directly  below  the  context  diagram  (called  the  Level  0  Diagram) 
represents  the  top-level  view  of  the  three  major  functions  of  the  system,  as  well  as  the 
interfaces  between  those  functions.  These  bubbles  are  numbered  1,  2,  and  3.  Each  of 
these  three  processes  is  associated  with  a  lower-level  DFD  (Figures  8,  9,  and  10  respec¬ 
tively). 

2.  Description  of  Dataflow 

The  DFDs  can  be  examined  by  tracing  the  flow  of  data  in  Figure  7  using  the 
objects  defined  in  the  preceding  sections.  In  Process  1  (Manage  Inventory),  the  Gunnery 
Ofiicer  Petty  Officer  updates  information  on  the  ship  (COMMAND  object)  as  required 
and  uses  updated  fleet  instructions  and  references  to  update  the  ARMIRS  rule  base 
(explained  in  greater  detail  later  in  this  thesis).  The  inventory  cards  (representing  the 
AMMO  INVENTORY,  SERIAL,  LOT,  and  SERIAL  &  LOT  CONTROLLED 
AMMO  objects)  are  updated  as  onloaded  ammunition  is  received  and  checked.  Other 
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inventor}'  modifications  (new  instances  of  the  TRANSACTION  object)  are  generated 
when  ammunition  is  expended.  Updated  allowances  are  also  processed  and  Notices  of 
Ammunition  Reclassification  (NARs)  are  compared  to  the  AMMO  INVENTORY  in¬ 
stances  to  determine  which  NARs  pertain  to  the  command. 

The  process  of  generating  requisitions  (Process  2)  begins  with  the  user's  decision 
on  desired  ammuntion.  After  reviewing  the  Requisition  File  (representing  properties  in 
the  REQUISITION  object)  and  using  ship  (COMMAND  object)  information  with  the 
system  rules,  a  requisition  header  (new  instance  of  the  REQUISITION  object)  is  cre¬ 
ated.  After  selecting  the  desired  requisition  format,  multiple  items  (REQN  LINE  ITEM 
object)  are  added  to  the  message  header  to  include  the  desired  ammunition.  After  the 
requisition  is  sent,  requisition  status  messages  are  periodically  received  onboard.  The 
information  from  these  messages  is  used  to  update  entries  in  the  Requisition  Log  (up¬ 
dating  the  REQN  LINE  ITEM  and  REQN  objects).  A  similar,  but  simpler,  process  is 
used  to  generate  turn-in  documents.  Only  one  format  is  used  for  the  DD  Form  1348 
turn-in  document  that  accompanies  offloaded  ammunition. 

The  third  major  function  of  the  shipboard  ammunition  management  system 
generates  internal  and  external  reports.  Internal  summary  reports  may  draw  data  from 
all  the  files  (and  from  all  the  objects)  in  the  system  to  produce  a  variety  of  reports  for 
shipboard  decision  makers  in  response  to  user  queries.  For  example,  Serial'Location 
cards  in  the  inventor}'  card  file  (SERIAL  and  SERIAL  &  LOT  CONTROLLED 
AMMO  objects)  are  reviewed  for  a  report  on  ordnance  with  soon-to-expire  maintenance 
due  dates.  Allowance  data  from  the  Master  Stock  Record  Cards  (AMMO  INVEN¬ 
TORY  object)  is  compared  with  current  balance  (posted  from  TRANSACTIONS)  to 
produce  a  report  allowing  the  tracking  of  training  allowance  expenditures  throughout 
the  fiscal  year.  ATRs  are  also  produced  by  Process  3.  Every  inventory  transaction 
(corresponding  to  new  instances  of  the  TRANSACTION  object)  requires  a  transaction 
report  that  draws  information  from  the  inventor}'  cards  (and  objects),  the  ship  (COM¬ 
MAND  object)  information,  and  the  rule-based  expertise  (e.g.,  determining  the  ATR 
addressees). 

The  dataflow  diagrams  in  Appendix  C  illustrate  the  three  key  ARM  IRS  func¬ 
tions  discussed  above:  inventor}'  processing,  requisition  management,  and  report  gener¬ 
ation.  Obviously  some  of  these  processes  seem  to  overlap  (e.g.,  both  Process  1  and 
Process  3  update  instances  of  the  TRANSACTION  object).  Figure  H  in  Appendix  C 
helps  relate  the  three  ammunition  management  functions  to  the  eight  objects  defined 
earlier  in  this  chapter.  Rather  than  using  several  logs  and  files  to  store  information,  a 
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single  database  is  used  to  store  the  objects.  The  three  ARM  IRS  functions  read  and/or 
write  object  information  as  shown  by  the  arrows  in  Figure  11.  The  specific  functional 
components  of  these  applications  and  objects  are  discussed  in  the  following  sections. 

3.  Application  Functional  Components 
a.  Inventory  Management 

The  inventory'  management  process  (Process  1)  reads  and  writes  four  objects 
as  discussed  below: 

( 1)  Read  and  Write  the  COMMAND  Object.  As  shown  in  the  Level  0 
.Diagram  (Figure  7),  the  Gunnery'  Officer  (through  Process  1)  writes  the  COMMAND 
object  which  is  later  read  to  generate  requisitions  (Process  2)  and  reports  (Process  3). 
Figure  12  in  Appendix  D  shows  the  form  used  to  both  update  and  display  the  COM¬ 
MAND  object.  When  the  ARM  IRS  system  is  first  installed  aboard  a  ship,  the  Database 
Adminstrator  enters  the  UIC,  command  name,  hull  number,  and  service  code.  This  in¬ 
formation  will  not  change  as  long  as  the  system  remains  onboard  and  the  ship  remains 
in  commission.  As  the  ship's  location  and  fleet  commander  change,  this  form  is  also  used 
to  update  the  database.  For  each  requisition  or  transaction,  information  on  the  other 
command  involved  (either  another  ship  or  a  weapons  station)  is  entered.  This  form  is 
also  used  to  display  command  information  even  when  updating  is  not  required. 

(2/  Read  and  Write  the  AMMO  INVENTORY  Object.  As  shown  in 
Figure  11,  the  inventory  management  process  reads  and  writes  ammunition  inventory 
data.  This  information  is  entered  into  the  database  by  a  form  similar  to  the  one  shown 
in  Figure  13.  This  form  captures  information  in  the  AMMO  INVENTORY  object  and 
is  similar  to  the  Master  Stock  Record  Form  used  in  the  manual  system.  The  upper  part 
of  the  form  is  used  to  record  descriptive  information  (AMMO  INVENTORY  object) 
about  a  particular  NIIN  held  in  inventory.  This  form,  like  the  Command  Information 
Form  discussed  above,  is  used  both  to  update  (including  creation  or  modification  of  an 
object  instance)  and  display  information  in  response  to  user  queries.  For  example,  if  the 
user  wished  to  see  all  of  the  inventory  records  for  torpedoes,  he  would  enter  the  torpedo 
COG  of  4T  in  the  "COG"  field  in  Figure  13.  Using  the  query-by-example  facility,  the 
user  would  then  be  able  to  page  through  a  series  of  inventory  screens  (Figure  13)  for 
torpedoes.  As  a  result,  the  inventory  form  is  a  dual  purpose  form.  Some  of  the  data  in 
the  form's  fields  would  be  typed  in  by  the  user  and  others  would  be  provided  by  the 
database,  depending  on  whether  append  (update  for  a  new  instance),  update,  or  display 
options  were  selected  from  a  system  menu. 
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The  update  and  display  mechanisms  used  with  this  object  (as  well  as 
for  the  other  objects  discussed  below)  are  fully  described  in  Appendix  E. 

(3)  Read  and  Write  the  TRANSACTION  Object.  Changes  to  the  com¬ 
mand's  ammunition  inventory  are  made  through  use  of  the  form  shown  in  Figure  13  and 
discussed  above.  The  middle  part  of  that  form  is  used  to  update  and  display  information 
on  how  the  inventory  quantity  and  condition  have  changed  (TRANSACTION  object). 
The  bottom  area  on  the  Figure  13  form  is  used  for  more  detailed  information  on  the 
ATR  generated  (from  the  TRANSACTION  object)  for  each  transaction.  For  example, 
in  an  ammunition  receipt  transaction,  the  quantity,  date,  and  document  number  of  the 
DD  Form  134S  accompanying  the  ammunition  would  be  entered.  The  system  would  add 
the  old  balance  to  the  quantity  received  to  give  a  new  balance.  This  quantity  is  then 
posted  to  the  AMMO  INVENTORY  object  and  becomes  the  balance  brought  forward 
for  the  next  transaction.  The  expert  database  system  discussed  in  Chapter  VI  (when 
used)  would  provide  the  information  on  the  "Addressees"  field  of  Figure  13.  In  addition, 
the  lower  part  of  the  Serial  Lot  Information  Form  (Figure  14)  is  used  to  display 
TRANSACTION  data  for  ammunition  with  serial  and/or  lot  numbers.  Appendix  E  de¬ 
scribes  the  adding  (posting),  editing,  and  deleting  of  TRANSACTION  instances. 

(4)  Read  and  Write  LOT,  SERIAL,  and  SERIAL  &  LOT  AMMO 
Objects .  The  form  shown  in  Figure  14  is  also  used  to  update  and  display  database  in¬ 
formation  on  serial  and  lot  ammunition  in  the  inventory.  The  serial  and/or  lot  number 
is  entered  on  the  top  part  of  the  form.  The  lower  part  of  the  form,  drawn  from  the 
TRANSACTION  object,  allows  update  and  display  of  inventory  transactions  affecting 
SLIT-controlled  items.  For  example,  to  display  information  on  a  particular  Harpoon 
missile,  the  serial  number  would  be  entered  and  the  form  (corresponding  to  both  the 
Serial'Location  and  Lot/Location  cards  in  the  manual  system)  would  be  displayed  with 
all  applicable  data  fields  completed.  If  the  user  did  not  have  the  serial  number  available 
but  knew  the  NALC  for  Harpoon  missiles,  the  NALC  would  be  entered  in  the  query- 
by-forms  mode  and  the  user  could  page  through  a  series  of  screens,  one  screen  for  each 
Harpoon  missile  onboard. 

b.  Requisition  and  Turn-In  Generation 

The  requisition  and  turn-in  generation  process  uses  the  the  forms  discussed 
above  and  the  Requisition  Information  Form  (Figure  15)  to: 

(I)  Read  the  COMMAND  Object.  The  COMMAND  object  is  used  by 
this  process  to  furnish  data  on  the  originating  and  receiving  commands  for  ammunition 
requisition  and  turn-in  documents. 
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(2)  Read  the  AMMO  INVENTORY  Object.  Turn-in  documents  and 
requisitions  use  descriptive  ammunition  information  from  this  object. 

(3)  Read  the  TRANSACTION  Object.  As  discussed  in  the  detailed 
functional  component  descriptions  (Appendix  E),  the  generation  of  turn-in  documents 
requires  TRANSACTION  information. 

(4)  Read  SERIAL  and.'or  LOT  CONTROLLED  AMMO  Objects.  If  a 
turn-in  item  is  controlled  by  serial  number  or  lot  number,  then  the  applicable  object 
must  be  read  by  this  process  to  generate  turn-in  documents.  Items  are  not  requisitioned 
by  specific  serial  or  lot  numbers. 

(5)  Read  and  Write  REQUISITION  and  REQN  LINE  ITEM 
Objects.  Ammunition  requisitions  are  created,  updated,  and  displayed  using  the  form 
shown  in  Figure  15.  To  create  a  new  requisition,  the  user  would  enter  all  the  information 
shown  on  the  form.  REQUISITION  object  information  is  used  to  construct  the  message 
header.  The  individual  REQN  LINE  ITEM  instances  are  created  by  completing  the 
lower  half  of  the  form.  As  requisition  status  messages  on  these  line  items  are  received 
by  the  ship,  the  "Status"  field  is  updated.  To  review  a  requisition,  the  user  would  type 
in  the  document  number  in  the  appropriate  field  and  the  system  would  display  that 
requisition. 

c.  Generate  Reports 

This  process  reads  all  eight  ARMIRS  objects  to  produce  ATRs  and  internal 
reports.  In  addition,  Process  3  writes  TRANSACTION  data  to  the  database  when  the 
ATR  serial  number  is  assigned  to  a  transaction. 

4.  Interapplication  Requirements 

Coordination  of  data  processing  and  the  sequential  relationship  between  Process 
1  (Manage  Inventor}’)  and  the  other  processes  (Generate  Requisitions  and  Generate 
Reports)  require  that  initial  data  entry  about  the  ship  and  the  ammunition  inventory  be 
completed  before  the  system  can  be  fully  utilized.  This  initial  entrv  is  accomplished  using 
the  forms  shown  in  Figures  13  and  14  as  previously  discussed.  If  an  item  is  controlled 
by  serial  and/or  lot  number,  a  Master  Stock  Record  must  be  created  before  transactions 
can  be  applied  and  posted.  Transactions  to  SLIT  items  must  be  processed  through  the 
transaction  section  of  the  form  in  Figure  13.  As  in  the  manual  system,  a  Serial  Lot 
Record  cannot  exist  without  the  parent  master  record. 

A  prerequisite  for  full  use  of  the  requisition  generation  function  (Process  2)  re¬ 
quires  information  on  the  commands  involved  (using  Figure  12)  as  well  as  user  input  on 
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the  type  and  quantity  of  ammunition  desired  (using  the  form  in  Figure  15).  The  user 
must  also  select  a  requisition  format  in  order  to  output  a  requisition. 

In  a  similar  way,  Process  3  (Generate  Reports)  requires  that  the  database  al¬ 
ready  contain  information  on  ammunition  and  requisitions  before  selected  reports  can 
be  considered  complete  and  accurate.  Transaction  reports  can  be  generated  only  after 
the  inventor)’  has  been  updated  to  reflect  the  balance  changes.  In  addition,  operation 
of  the  ATR  expert  database  system  (or  user  input  if  the  expert  system  is  not  used)  must 
be  completed  before  an  ATR  is  ready  for  transmission. 

5.  Operations  Requirements 

a.  System  Operation 

Because  of  the  high  frequencies  and  volumes  required  for  the  update  and 
display  activites  shown  in  Appendix  E,  full  use  of  ARM  IRS  requires  a  robust  and  de¬ 
pendable  system.  It  is  especially  important  that  the  system  is  fully  operational  during 
periods  of  high  ammunition  transaction  volume.  These  periods  include: 

•  Immediately  prior  to  a  deployment  when  major  ammunition  onloads  are  scheduled. 

•  Before  an  overhaul  period  when  ship-wide  offloads  are  required. 

•  After  drydock  periods  when  ammunition  magazines  must  be  refilled. 

•  During  refresher  training  and  other  training  periods  when  expenditure  of  ammuni¬ 
tion  is  high. 

•  After  combat  operations  requiring  ammunition  expenditure. 

•  Prior  to  repairs  in  or  near  ammunition  magazines  requiring  a  partial  offload. 

b.  Backup  and  Security 

Procedures  for  system  backup  and  security  contribute  toward  the  overall 
operational  readiness  of  ARMIRS.  Backups  are  recommended  after  even’  three  to  four 
minor  transactions  or  weekly  (whichever  comes  first).  More  frequent  backups  may  be 
required  if  system  volumes  and  frequencies  exceed  those  shown  in  Appendix  E.  In  addi¬ 
tion,  a  backup  copy  of  the  supporting  microcomputer  DBMS  should  be  stored  in  a  se¬ 
cure  location.  Strict  enforcement  of  backup  procedures  will  simplify  the  task  of  data  and 
system  recover)’. 

Although  an  essential  component  of  a  working  ARMIRS  system,  backup 
procedures  and  logic  are  not  specified  in  this  thesis.  A  variety  of  generic  microcomputer 
backup  tools  are  commercially  available.  Custom  design  of  ARM  IRS-specific  backup 
software  is  not  necessary  when  compatible  backup  software  is  so  common. 
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The  security  of  ARMIRS  data  also  requires  attention.  Some  ARMIRS  data 
(e.g.,  some  ATRs  and  requisitions)  and  the  ammunition  inventory  taken  as  a  whole  are 
classified  Confidential.  Password  administration  and  control,  assigned  access,  physical 
security  of  the  microcomputer  (and  backup  data  disks),  and  protection  against  compro¬ 
mising  electronic  emissions  are  required.  As  with  backup  systems,  software  already  exists 
to  encrypt  data  and  protect  against  unauthorized  access.  Although  essential  to  eventual 
implementation,  the  specific  security  software  selected  does  not  impact  database  design 
and  is  beyond  the  scope  of  this  thesis. 
c.  Users 

The  users  of  ARMIRS  data  include: 

•  Routine  Users:  Gunnery  Officer,  ASW  Officer,  Gunner's  Mates  (Gun  and  Missile) 
and  Torpedomen. 

•  Database  Adminstrator  (Weapons  Officer)  to  establish  and  enforce  procedures  for: 

■  Database  backup  and  recovery 

■  Data  and  system  security  (passwords  and  physical  security) 

■  System  application  maintenance 

■  Training  of  system  users 

•  Occasional  (Query  Only)  Users:  CIC  Officer,  Operations  Officer,  Commanding 
Officer,  and  inspectors  receiving  ARMIRS  information  through  reports  processed 
by  routine  users  as  intermediaries. 

6.  Administrative  and  Environmental  Requirements 

As  Database  Administrator  (DBA),  the  Weapons  Officer  will  supervise  opera¬ 
tion  of  ARMIRS.  In  addition  to  the  specific  responsibilities  listed  above,  the  DBA  will 
be  responsible  for  initial  system  setup  and  bulk  data  entry.  During  initial  conversion 
from  the  manual  system,  a  large  volume  of  database  entries  will  be  made  as  data  is 
transferred  from  the  stock  record  cards,  ATR  logs,  and  requisition  files.  An  improved 
sytem  for  this  initial  bulk  data  entry  could  be  implemented  in  a  later  version  of 
ARMIRS. 

The  unique  and  demanding  shipboard  environment  imposes  additional  con¬ 
straints  on  hardware  requirements.  TEMPEST-approved  Zenith  248  microcomputers 
(PC  AT10  equivalents)  and  printers  are  available  on  many  Navy  ships  and  could  be  uti¬ 
lized  for  ARMIRS  use. 


10  PC  and  PC  AT  are  trademarks  of  International  Business  Machines  Corporation. 
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IV.  LOGICAL  AND  APPLICATION  DESIGN 


This  chapter  uses  the  objects  and  relationships  defined  in  Chapter  III  to  develop  the 
ARM  IRS  relational  schema.  This  view  of  the  object  relationships,  together  with  the 
previously  discussed  objcct/data  flows,  is  then  used  to  design  the  application  menus. 

A.  LOGICAL  DESIGN-TRANSFORMATION  OF  OBJECTS 

The  transformation  of  the  ARM  IRS  objects  into  relations  is  described  below  for 
each  object.  The  overall  view  (schema)  of  these  relations  is  shown  in  Appendix  F. 

1.  COMMAND  Object 

The  COMMAND  object  consists  of  two  multi-valued  object  properties  (REQ¬ 
UISITION  and  AMMO  INVENTORY)  and  eight  non-object  properties.  An  instance 
of  COMMAND  is  a  Navy  activity  identified  by  a  Unit  Identification  Code  (UIC).  The 
relation  shown  in  Appendix  F  shows  COMMAND  (with  UIC  as  the  key  attribute)  as 
the  parent  relation  and  REQUISITION  (keyed  on  Document  Number)  as  one  child  and 
AMMO  INVENTORY  (with  NUN  as  the  key)  as  another. 

Both  relationships  are  described  as  one-to-many.  This  type  of  relationship  is 
shown  as  a  forked  line,  with  the  fork  on  the  "many"  side  of  the  relationship.  One  com¬ 
mand  has  many  NIINs  in  its  ammunition  inventory  and  many  Document  Numbers  in 
its  Requisition  Log.  In  a  one-to-many  relationship,  the  key  of  the  parent  relation  (UIC) 
is  placed  as  a  foreign  key  in  the  child  relation.  Both  relationships  have  a  mandatory-to- 
optional  constraint.  Every  requisition  must  belong  to  a  command  (actually  two  COM¬ 
MANDS,  the  ARM  IRS  ship  [S_LTCj  and  the  other  command  involved  in  a  transaction 
[0_LTC]).  However,  it  is  possible  to  have  a  command  without  a  requisition.  An  inven¬ 
tory  item  exists  somewhere;  it  always  belongs  to  a  command.  However,  a  command  (in 
the  ARM  IRS  view)  would  not  exist  without  an  ammunition  inventor}'.  In  the  relation 
diagram  (Figure  16),  the  circle  shows  the  optional  side  while  the  bar  shows  the  manda¬ 
tory  side. 

2.  REQUISITION  &  REQN  LINE  ITEM  Objects 

The  REQUISITION  object  consists  of  two  COMMAND  object  properties,  one 
multi-value  object  property  (REQN  LINE  ITEM),  one  multi-value  non-object  property 
(Addressees),  and  five  single-value  non-object  properties.  The  Document  Number 
uniquely  identifies  a  single  requisition. 
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REQN  LINE  ITEM  includes  several  single-value  non-object  properties  and  two 
single-value  object  properties  (REQUISITION  and  AMMO  INVENTORY).  An  in¬ 
stance  of  this  object  is  a  line  on  a  requisition  identified  by  requested  NIIN.  This  NUN 
may  or  may  not  be  a  NIIN  currently  in  INVENTORY. 

The  relationship  between  REQUISITION  and  REQN  LINE  ITEM  is  clearly 
one-to-many.  A  requisition  has  one  or  more  ammunition  items  on  it,  but  the  line  items 
belong  to  one  requisition.  A  parent-child  relationship  exists  and  Document  Number 
becomes  a  foreign  key  in  REQN  LINE  ITEM.  This  is  a  mandatory-mandatory  re¬ 
lationship  because  a  requisition  must  have  at  least  one  line  item  (or  the  ship  would  not 
be  requisitioning  anything)  and  a  line  item,  could  not  exist  alone  without  a  requisition 
header. 

Requisition  Addressee  is  a  multi-value  non-object  property  of  REQUISITION. 
Like  all  composite  objects,  more  than  one  relation  is  required  for  representation.  One 
requistion  must  have  multiple  information  or  action  addressees.  Document  Number  is 
therefore  a  key  (and  also  a  foreign  key)  in  the  REQ-ADDR  relation. 

3.  AMMO  INVENTORY  Object 

The  large  AMMO  INVENTORY  object  consists  of  five  multi-value  objects,  a 
single-value  object  (COMMAND),  two  multi-value  properties  (Mission  Area  and 
Stowage  Location),  and  many  properties  with  single  values.  A  NIIN  uniquely  identifies 
a  particular  type  of  ammunition  in  inventor}7. 

There  is  a  one-to-many  relationship  between  AMMO  INVENTORY  and  both 
the  REQN  LINE  ITEMS  and  TRANSACTION  objects.  As  a  result  NIIN  becomes  a 
foreign  key  in  the  child  relations.  The  relationship  between  INVENTORY  and 
TRANSACTION  is  mandatory-mandatory  because  a  NIIN  instance  (a  Master  Stock 
Record  Card)  will  always  have  at  least  one  transaction  (even  if  it  is  only  the  balance 
change  that  brought  it  to  the  ship).  Of  course,  a  balance  change  could  not  exist  without 
a  parent  inventory. 

Two  composite  objects  (AMMO-M1SSN  and  NON-LOT  LOC)  are  also  re¬ 
presented  in  the  relational  AMMO  INVENTORY  schema.  Operational  reporting  (i.e., 
SORTS  message)  requirements  require  shipboard  personnel  to  assign  one  or  more  com¬ 
bat  mission  areas  to  a  NUN  if  the  item  supports  an  identifiable  combat  mission.  A  NIIN 
may  have  more  than  one  mission  area.  For  example,  a  certain  type  of  5-inch  gun 
projectile  could  be  used  both  in  anti-surface  (ASUW  mission  area)  and  naval  gunfire 
support  (AMW  mission  area)  roles.  Assignment  of  these  SORTS  report  mission  areas 
is  not  required  for  all  NlINs;  some  inventory  items  (e.g.,  small  arms  ammunition  and 
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pyrotechnics)  are  not  assigned  to  mission  areas.  The  relational  diagram  shows  this  one- 
to-many,  mandatory-optional  relationship. 

The  second  AMMUNITION  INVENTORY  composite  object  is  NON-LOT 
LOC.  This  relation  expresses  the  assignment  of  multiple  shipboard  stowage  locations 
to  non-SLIT  NUNs.  (Assigning  locations  to  the  serial  and/or  lot  items  is  handled  in 
other  relations.)  One  NIIN  may  be  distributed  to  many  ammunition  lockers  and  maga¬ 
zines.  Every  NIIN  onboard  must  have  a  shipboard  stowage  location.  An  empty  stowage 
location  is  not  of  concern  for  ARM  IRS  purposes. 

4.  TRANSACTION  Object 

As  discussed  in  the  preceding  section,  TRANSACTION  is  the  child  relation  in 
the  one-to-many  relationship  between  AMMO  INVENTORY  and  TRANSACTION. 
As  a  result,  TRANSACTION  inherits  NIIN  as  a  foreign  key. 

Each  transaction  has  multiple  addressees  for  the  ATR.  A  transaction  cannot  be 
considered  complete  without  ATR  addressees.il  This  composite  object  is  also  shown  in 
the  relational  diagram. 

The  relationship  between  TRANSACTION  and  the  three  SLIT  categories  is 
discussed  in  the  next  section. 

5.  SERIAL  and/or  LOT  CONTROLLED  AMMO  Objects 

These  three  objects,  like  their  siblings  TRANSACTION  and  REQN  LINE 
ITEMS,  are  characterized  by  one  (AMMO  INVENTORY)  to  many  (SERIAL  and/or 
LOT  CONTROLLED  AMMO)  relationships.  In  each  case,  the  key  of  the  parent 
(NUN)  becomes  a  foreign  key  in  the  child  relation. 

All  three  of  these  relationships  with  AMMO  INVENTORY  are  mandatory- 
optional.  An  inventory  item  may  be  non-SLIT  (having  neither  serial  nor  lot  numbers). 
However,  the  SLIT  items  can  only  exist  as  a  part  of  inventory';  they  can  have  no  exist¬ 
ence  alone. 

Each  of  the  SLIT  objects  contain  TRANSACTION  as  a  multi-value  object 
property,  shown  as  three  one-to-many  relationships  in  Figure  16.  Lot  Number  and  Serial 
Number  are  foreign  keys  in  this  relation.  For  non-SLIT  items,  these  foreign  keys  would 
have  null  values.  As  with  the  AMMO  INVENTORY  object,  the  three  SLIT  relations 
must  always  have  at  least  one  transaction  (even  if  it  is  just  the  receipt  transaction  from 
an  initial  onload).  Of  course,  a  TRANSACTION  instance  could  apply  to  a  non-SLIT 
item. 


1 1  The  rules  for  determining  these  addressees  is  shown  in  Appendix  L. 
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Shipboard  stowage  location  is  a  composite  object  (LOT-LOCATION)  for  am¬ 
munition  controlled  only  by  lot  number.  A  lot  may  be  distributed  among  multiple  am¬ 
munition  lockers  and  magazines.  A  lot  number  in  inventory  must  have  a  shipboard 
stowage  location.  Again,  there  is  no  requirement  to  recognize  empty  lockers  and  maga¬ 
zines. 

Ammunition  controlled  by  serial  number  has  location  as  a  single-value  property 
because  a  serial  number  designates  one  ammunition  round  with  only  one  location. 

B.  APPLICATION  DESIGN 

1.  Application  Scope 

As  previously  discussed,  application  of  ARM  IRS  falls  naturally  into  three  pri¬ 
mary  functions:  inventory  management,  requisitioning,  and  report  generation.  Routine 
ARM  IRS  users  are  involved  in  all  three  processes;  occasional  (query-only)  users  include 
middle  and  upper  management  whose  interaction  with  ARMIRS  is  only  through  the 
report  generation  function,  often  with  the  Gunnery  Officer  as  intermediary.  All  of  the 
ARMIRS  processing  responsibilities  could  be  handled  by  one  person,  if  necessary.  Ob¬ 
viously  a  single-user  application  is  appropriate.  In  ARMIRS,  each  user's  view  is  fully 
inclusive.  Of  course,  some  restrictions  on  access  are  desirable  to  protect  classified  in¬ 
ventory  data.  These  security  mechanisms  (e.g.,  password  systems,  encrypted  data,  etc.) 
will  be  provided  by  software  outside  ARMIRS  or  other  (e.g.,  physical  security)  safe¬ 
guards. 

All  three  of  the  ARMIRS  functions  can  be  run  from  the  same  microcomputer. 
This  microcomputer  could  be  located  in  the  Weapons  Department  office  where  many 
ships  maintain  their  manual  records.  The  frequencies  and  volumes  shown  in  Appendix 
E  make  it  clear  that  a  single-user  system  is  appropriate,  even  on  larger  ships.  There  is 
not  even  a  requirement  to  put  certain  ARMIRS  functions  on  different  shipboard  com¬ 
puters.  All  authorized  ARMIRS  users  would  have  the  same  processing  rights. 

2.  Control  Mechanisms 

a.  Selection  of  Control  Method 

One  of  the  most  important  decisions  in  the  design  of  the  ARMIRS  user 
interface  is  the  selection  of  the  transaction  control  method,  since  it  determines  how  and 
whether  the  shipboard  user  will  be  able  to  control  the  application.  A  menu-driven  system 
would  minimize  cognitive  demands  on  ARMIRS  users.  Users  would  not  need  to  learn 
any  special  function  keys  or  commands.  Menu  screens  show  tb<*  only  options  available 
at  the  time;  the  users  do  not  have  to  recall  specific  system  functions. 
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This  does  not  mean  that  menus  are  without  problems.  Experienced  users, 
while  finding  menus  helpful  at  first,  may  find  them  tedious  after  they  learn  ARM  IRS. 
Having  to  step  through  a  series  of  menu  screens  can  be  time-consuming  and  frustrating 
for  the  sophisticated  user.  The  use  of  function  keys  and  commands  is  appropriate  for  a 
user  who  uses  the  application  frequently  (i.e.,  the  Gunnery  Officer  in  the  ARMIRS 
case). 

The  best  solution  would  be  to  provide  ARMIRS  users  with  both  menus  and 
commands  to  control  the  system.  A  user  could  then  choose  between  the  two  methods. 
This  thesis  specifies  the  menu  system  for  ARMIRS.  Design  of  a  command  language  is 
not  required.  Many  microcomputer  DBMSs  support  a  query  language,  such  as  the 
ANSI-standard  Standard  Query  Language  (SQL).  When  selecting  a  DBMS  for 
ARMIRS  implementation,  query  language  support  should  be  an  important  consider¬ 
ation. 

b.  Menu  System 

The  diagrams  in  Appendix  G  illustrate  the  multiple  choice,  multiple  path 
ARMIRS  menus.  As  shown  in  Figures  17  through  20,  a  simple  tree  structure  allows  the 
user  to  make  a  series  of  choices  that  take  him  down  through  lower  layers  of  menus  until 
reaching  the  desired  destination.  The  top-level  menu  shown  in  Figure  17  is  the  ARMIRS 
main  menu  consisting  of  the  basic  system  options.  Implementation  of  ARMIRS  should 
include  designation  of  one  keystroke  to  return  to  this  menu  from  anywhere  in  the  menu 
hierarchy. 

ARMIRS  uses  the  "object-action"  strategy  of  menu  design.  The  top  menu 
(Menu  0)  refers  to  three  broad  object  categories:  (1)  inventory  objects  (AMMO  IN¬ 
VENTORY,  TRANSACTION,  SERIAL  and, or  LOT  CONTROLLED  AMMO),  (2) 
requisition  objects  (REQUISITION,  REQN  LINE  ITEM),  and  (3)  the  Navy  activity 
object  (COMMAND).  When  the  user  selects  one  of  these  options,  the  lower  menus  lead 
him  to  select  an  action  (e.g.,  add,  edit,  generate)  to  be  performed  on  the  objects.  Kroenke 
and  Dolan  (19S8,  pp.  269-270)  point  out  that  this  object-action  design  is  closer  to  most 
users'  perspective  than  the  alternative  action-object  structure. 

If  a  user  selects  one  of  the  four  sub-menus  shown  in  Figure  17,  he  is  pre¬ 
sented  with  either  a  third-level  menu  (Figures  18,  19,  and  20)  or  a  form/ report  (ifhc  has 
arrived  at  an  option  that  does  not  chain  to  a  lower  menu).  This  menu  structured  is  out¬ 
lined  in  the  next  section. 
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3.  Logic  and  Design  Materialization 

The  top  ARM  IRS  menu  provides  the  initial  user  interface  and  provides  five  in¬ 
itial  options: 

1.  Inventor}7  Management 

2.  Requisition-Turn-Ins 

3.  Reports 

4.  Ship  Information^ 

5.  Exit  to  Operating  System 

Selection  of  these  first  four  choices  result  in  the  menus  outlined  below: 

1.  Inventory  Management 

a.  Master  Stock  Records 

1)  Append 

2)  Edit 

3)  Query/Display 

b.  Serial.  Lot  Records 

1)  Append 

2)  Edit 

3)  Query.'Display 

c.  Process  Transactions 

1)  Add  Transaction 

2)  Delete  Transaction 

3)  Edit  Transaction 

2.  Requisitions.'Turn-lns 

a.  Append 

b.  Edit 

c.  Query,'  Display 

d.  Generate  Requisition, 'Turn-In 

1)  DD-134S  Requisition 

2)  DD-134S  Turn-In 

3)  DAAS  Requisition 

12  Selected  by  the  user  on  a  separate  menu  but  functionally  part  of  the  inventor}’  management 
process. 
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4)  Naval  Message  Requisition 

3.  Generate  Reports 

a.  Inventory  Reports 

1)  Inventory  Summary  Report 

2)  Allowance  List  Report 

3)  NAR  Management  Report 

4)  Allowance  Tracking  Report 

5)  SORTS  Message  Input 

6)  Ship  Ammunition  Inventory  (Summary) 

7)  Ship  Ammunition  Inventory  (Detailed) 

8)  Maintenance  Due  Summary  Report 

b.  Transaction  Reports 

1)  ATR  Generation 

2)  ATR  Log 

c.  Requisition; Turn- In  Reports 

1)  Requisition  Log 

2)  Turn-In  Log 

3)  Outstanding  Requisition  Report 

4.  Ship  Information 

a.  Edit  Ship  Data 

b.  Display  Ship  Data 

The  detailed  logic  for  each  of  these  menu  options  and  reports  is  described  in 
Appendix  H.  Ever}'  menu  path  is  described  in  a  Structured  English  pseudocode  that  de¬ 
fines  the  ARM  IRS  system  logic.  Structured  English  borrows  logical  constructs  from 
computer  programming  languages.  However,  the  use  of  computer  jargon  is  avoided  and 
the  specification  is  easier  for  system  designers  and  imp'ementers  to  understand.  The  use 
of  Structured  English  in  Appendix  H  to  define  the  ARMIRS  menu  and  processing  logic 
avoids  many  of  the  limitations  and  ambiguities  of  ordinary  English  but  does  not  limit 
understanding  only  to  those  who  know  a  particular  computer  programming  language. 
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V.  PHYSICAL  DATABASE  DESIGN 


This  chapter  translates  the  relational  schema  into  a  series  of  linked  tables  using 
PARADOX.  After  defining  these  tables,  the  ARMIRS  reports  are  implemented. 

A.  DBMS  OVERVIEW 

Recall  that  objects  are  not  stored  in  a  database;  they  represent  things  in  the  user's 
work  environment.  There  is  not  yet  a  DBMS  product  that  actually  stores  objects 
(Kroenke  and  Dolan,  1988,  pp.  256-257).  In  the  previous  chapter,  the  ARMIRS  objects 
were  transformed  into  relations.  When  the  user  enters  a  query  about  an  object,  the 
DBMS  constructs  the  object  from  data  in  several  tables.  The  process  of  creating  these 
tables  (in  the  data  model  of  a  particular  DBMS  software  package)  is  called  materializing 
the  objects.  In  this  chapter,  the  abstract  ARMIRS  objects  and  relations  are  implemented 
into  a  series  of  tables  which  a  DBMS  uses  in  running  the  application. 

The  first  step  in  this  materialization  process  is  selecting  a  particular  DBMS  data 
model.  Three  microcomputer  DBMS  software  packages  were  available  for  ARMIRS 
object  materialization:  (1)  INGRES  for  PCs  (Version  5.0),  13  (2)  DBASE  III,  and  (3) 
PARADOX  (Version  3.0). 

INGRES  is  strongly  based  in  relational  database  theory;  it  has  a  pedigree  that 
streches  back  to  university  research  in  the  relational  model  from  the  early  1970s.  In¬ 
stalled  at  several  thousand  sites  worldwide,  this  DBMS  has  directly  or  indirectly  influ¬ 
enced  the  design  of  several  other  relational  systems  (Date,  1987,  p.  iv).  INGRES  runs 
in  may  different  environments  (e.g.,  VMS,  UNIX,  VM/CMS,  and  MS-DOS),  but  is  not 
widely  used  on  microcomputers.  The  author's  previous  INGRES  application  develop¬ 
ment  experience  (Buzzard,  et.  ai,  19S9)  resulted  in  an  appreciation  of  the  power  of 
INGRES  but  disatisfaction  at  the  error-prone  PC  implementation  of  this  mainframe- 
oriented  DBMS.  INGRES  supports  SQL  and  includes  a  visual  forms  editor  allowing 
form  definition  directly  on  the  screen.  Reports  are  specified  in  lines  of  INGRES  report 
specification  code.  INGRES  implementation  would  support  the  ARMIRS  application 
through  the  use  of  a  form  or  example  query  facility  (as  specified  in  the  requirements 
analysis).  1 


13  INGRES  is  a  trademark  of  Relational  Technology,  Inc. 


L 


36 


DBASE  III  was  considered  for  ARMIRS  object  materialization  because  it  has  be¬ 
come  the  de  facto  microcomputer  DBMS  standard.  (Although  advertised  as  "relational", 
DBASE  III  and  IV  (along  with  FOXBASE  and  other  DBASE  language  dialects)  actually 
are  "relational-like"  file-based  systems.)  As  Smith  (19S7,  p.  48)  points  out,  the  wide¬ 
spread  use  of  DBASE  makes  it  a  good  candidate  for  use  in  eventual  ARMIRS  imple¬ 
mentation.  A  significant  disadvantage  of  DBASE  is  its  relatively  poor  application 
development  facility.  Where  INGRES  uses  a  visual  editor  to  design  screens  (forms  and 
menus),  DBASE  requires  programming  lines  of  x,y  SAY..."  commands  to  specify  the 
location  of  all  screen  elements.  In  contrast  to  the  fourth  generation  language  (4GL)  used 
in  INGRES  application  development,  DBASE  uses  more  traditional  (and  more  difficult) 
coding  techniques.  < 

PARADOX  combines  the  full  power  and  application  development  tools  of  INGRES 
with  the  widespead  acceptance  and  PC  robustness  of  DBASE  III.  In  PARADOX,  both 
forms  and  reports  are  specified  visually,  requiring  no  coding.  A  query-by-cxamplc  Facility 
is  also  present.  PARADOX'S  ease  of  use  aided  object  materialization  for  this  thesis  and 
make  it  a  prime  candidate  for  use  in  future  ARMIRS  application  development. 

B.  CONSTRUCTING  THE  TABLES  IN  PARADOX 

ARMIRS  objects  were  materialized  using  a  multitable  design.  Using  the  previously 
defined  object  definitions  and  domain  definitions,  field  names  were  assigned  and  field 
types  were  specified.  Figure  21  in  Appendix  I  shows  how  the  AMMO  INVENTORY 
object  was  tranformed  into  a  table.  All  of  the  single-value  non-object  attributes  are  listed 
with  the  key  attribute  (AMMO  INVENTORY.NIIN)  listed  first  and  shown  with  an  as¬ 
terisk.  The  domain  definitions  were  then  used  to  enter  the  appropriate  field  type  in  the 
table  definition  form.  The  domain  definitions  were  adjusted  if  required  to  fit  the  PAR¬ 
ADOX  syntax  while  preserving  the  previously  defined  ARMIRS  physical  constraints. 
For  example,  the  attribute  FSC  consists  of  four  numerals,  which  can  include  leading 
zeros  (e.g.,  0087)  important  for  precisely  formatted  reports.  If  the  PARADOX  "number" 
format  had  been  specifed  in  Figure  21,  the  FSC  of  0087  would  become  87  when  the 
leading  zeros  were  removed.  FSC  is  therefore  defined  as  type  A  (for  alphanumeric)  with 
four  digits,  even  though  non-numeral  characters  would  never  appear  in  an  FSC.  As  a 
result,  the  leading  zeros  are  preserved.  This  format  change  is  not  a  disadvantage  for  FSC 
because  computations  are  not  performed  on  this  attribute. 

However,  there  are  cases  when  we  want  to  implement  a  mask  as  a  validity  check. 
This  thesis  previously  defined  the  physical  attributes  of  the  domain  definitions  in  Ap- 
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pendix  B.  During  the  implementation  of  ARM  IRS  into  the  PARADOX  model,  these 
constraints  on  valid  data  were  also  specified.  In  PARADOX,  as  in  other  DBMS  pro¬ 
ducts,  we  want  to  supplement  the  information  in  the  field  description  so  that  when  the 
user  enters  data,  the  system  will  automatically  check  not  only  on.  the  field  type  but  also 
on  other  requirements.  For  example,  using  validity  checks  makes  it  possible  to  specify 
that  in  the  tw’o  character  alphanumeric  COG  Symbol  the  first  character  is  a  number  and 
the  second  character  is  a  capital  letter.  PARADOX  then  enforces  these  requirements 
whenever  values  are  entered  or  changed.  In  PARADOX  it  is  possible  to  enter  validity 
checks  on  (1)  a  minimum  value  (e.g.,  the  minimum  FAD  is  "1"),  (2)  a  maximum  value 
(e.g.,  the  maximum  value  on  Required  Delivery  Date  is  366),  (3)  a  default  value  (e.g.,  if 
Activity  Classification  Code  is  not  entered,  the  default  value  of  "A"  indicating  combatant 
ships  and  submarines  will  be  used),  and  (4)  a  "picture"  of  the  exact  format.  These  validity 
checks  for  the  ARMIRS  PARADOX  tables  are  shown  in  Appendix  J. 

After  defining  the  data  implementation  from  the  objects  and  specifying  the  validity 
checks  from  the  domain  definitions,  the  next  step  is  to  use  the  relational  schema  to  de¬ 
fine  relationships  between  the  tables.  The  several  one-to-many  relationships  are  defined 
by  how  the  tables  are  set  up.  For  example,  the  AMMO  INVENTORY  relation  is  char¬ 
acterized  by  seven  one-to-many  relations: 

1.  One  AMMO  INVENTORY  (NUN)  to  many  Mission  Areas 

2.  One  AMMO  INVENTORY  (NUN)  to  many  TRANSACTIONS 

3.  One  AMMO  INVENTORY  (NUN)  to  many  Stowage  Locations 

4.  One  AMMO  INVENTORY  (NUN)  to  many  REQN  LINE  ITEMS 

5.  One  AMMO  INVENTORY  (NIIN)  to  many  LOT  CONTROLLED  AMMO 

6.  One  AMMO  INVENTORY  (NUN)  to  many  SERIAL  CONTROLLED  AMMO 

7.  One  AMMO  INVENTORY  (NUN)  to  many  SERIAL  &  LOT  AMMO 

The  materializations  of  these  one-to-many  relations  of  AMMO  INVENTORY  are 
listed  in  Figure  22.  Each  of  these  detail  tables  is  shown  in  Figures  23  through  29.  Notice 
that  these  detail  tables  (for  the  "many"  side  of  the  relationship)  reflect  the  multi-value 
object  attributes  in  AMMO  INVENTORY  in  addition  to  the  multi-value  non-object 
properties.  They  were  created  by  placing  NUN,  the  key  of  AMMO  INVENTORY,  on 
the  first  line  of  the  detail  tables  (but  this  time  without  an  asterisk).  The  master  and  detail 
tables  are  then  linked. 

Figure  30  shows  the  materialization  of  the  TRANSACTION  object.  Since  the  at¬ 
tribute  ATR  Addressees  is  a  multivalue  property  of  TRANSACTION,  the  detail  table 
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in  Figure  31  was  constructed  using  the  procedure  discussed  above.  ATR  Serial  Number 
is  listed  first  (again,  without  an  asterisk)  in  the  detail  table.  Figures  32  through  42  show 
how  a  similar  procedure  was  used  to  define  and  link  the  remaining  ARM  IRS  relation¬ 
ships. 

C.  REPORT  SPECIFICATION  IN  PARADOX 

After  defining  how  one  table  is  linked  to  another  in  the  multitable  ARM  IRS  data¬ 
base,  reports  were  implemented  for  these  multiple  tables.  This  process  involved  linking 
one  table  to  another  and  designing  their  shared  report. 

Before  producing  reports  on  this  multitable  database,  it  was  necessary  to  decide 
which  table  would  be  the  master  table  for  each  report.  In  a  database  like  ARM  IRS  de¬ 
scribed  by  one-to-many  relationships,  the  table  on  the  "many"  side  of  the  relationship 
must  be  the  master  report  table  while  the  table  on  the  "one"  side  (which  had  the  key  field 
designated  with  an  asterisk)  is  the  detail  "lookup"  table.  When  choosing  which  table  to 
make  the  master  table  of  these  reports,  the  table  that  can  be  linked  to  the  most  detail 
tables  is  the  best  candidate.  The  ARMIRS  reports  implemented  in  PARADOX  (and 
shown  in  the  Appendix  K  custom  report  specifications)  fell  into  three  main  categories: 
(1)  single  table  reports,  (2)  multiple  table  (linked)  reports,  and  (3)  complex  multiple  table 
reports  requiring  queries. 

The  easiest  type  of  report  to  implement  (and  also  the  rarest  in  ARMIRS)  was  the 
single  table  report.  For  example,  the  Ship  Ammunition  Listing  Report  (Figure  43  in 
Appendix  K)  and  the  Allowance  List  Report  (Figure  44)  both  came  directly  from  the 
unlinked  master  ammunition  table  (M_inv).  The  table  was  first  transformed  into  a  de¬ 
fault  tabular  report  format.  Editing  the  field  displays,  editing  the  columns,  and  revising 
the  headings  (e.g.,  placing  the  date  in  the  heading  of  each  report)  gave  final  form  to  the 
visual  report  specification.  Grouping,  which  controls  how  the  report  information  is 
sorted  and  divided,  was  then  added.  As  shown  in  Figure  43,  PARADOX  report  specifi¬ 
cations  include  the  group  bands  that  enclose  the  report  table.  In  the  Ship  Ammunition 
Listing,  COG  is  the  most  significant  grouping  and  defines  the  principal  sort.  It  is  fol¬ 
lowed  by  NALC,  the  next  inner  group. 

The  second  type  of  report,  the  linked  table  report,  was  the  most  common.  After 
deciding  which  table  should  be  the  master  table,  a  report  is  designed  on  this  table  by 
linking  the  master  table  to  the  lookup  tabie.  This  provides  access  to  the  fields  in  both 
tables  which  can  be  selected,  edited,  and  placed  on  the  report.  Figure  45  is  an  example 
of  this  type  of  linked  table  report.  The  Allowance  Tracking  Report  is  creating  by  linking 
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a  table  (M_inv)  derived  from  the  AMMO  INVENTORY  object  with  a  table  (Am_bal) 
formed  from  the  TRANSACTION  object.  Recall  that  the  table  "Am_bal"  was  on  the 
"many"  side  of  the  relationship  and  "M_inv"  was  on  the  "one"  side.  The  two  tables  are 
linked  together  with  "M_inv"  as  the  lookup  table  and  "Am_bal"  as  the  master  table. 
After  extensive  editing,  the  group  bands  are  added.  Notice  that  the  table  is  sorted  by 
NALC,  a  field  in  the  detail  (M_inv)  table.  Figure  45  also  illustrates  use  of  a  calculated 
field.  The  percentage  of  shipfill  allowance  onboard  is  calculated  for  this  report  and  does 
not  come  from  a  table.  The  upper  right  corner  of  the  report  shows  the  specification  for 
this  calculated  field.  Figures  46  through  48  also  illustrate  the  features  of  the  linked  table 
report. 

The  final  type  of  report  also  uses  linked  tables  but  in  a  slightly  different  way.  In 
PARADOX,  it  is  not  possible  to  link  lookup  tables  to  other  lookup  tables.  In  the  case 
of  several  ARM  IRS  tables,  it  was  therefore  not  possible  to  include  these  tables  in  a 
single  report  using  the  link  commands.  In  these  cases,  it  was  necessary  to  compose  a 
query  that  joined  all  the  desired  fields  into  a  single  "answer  table".  A  report  was  then 
generated  on  that  table.  The  reports  in  Figures  49  and  50  illustrate  this  type  of  report 
specification.  For  example,  the  SORTS  Message  Input  Report  (Figure  49)  uses  infor¬ 
mation  on  .rtkckiA  areas  (Am_mis)  and  balance  changes  (Am_bal)  with  inventory  in- 
forr.au>'n.  The  mission  area  and  balance  changes  are  both  on  the  "many"  side  of  the 
oj unto -many  relationship  with  the  inventory  table  (keyed  by  NUN).  It  was  possible  to 
in  k  f.U'sc  tables  only  by  querying  them  on  the  desired  report  fields  and  sending  the 
output  *o  a  ral*l  ’  specifically  designed  for  this  report  (Sorts_rp).  The  report  specification 
was  tb'n  designed  from  this  answer  table.  The  NAR  Management  Report  in  Figure  50 
is  another  example  of  this  type  of  report.  Because  of  the  the  one-to-many  relationship 
between  ammunition  inventory  [the  one]  and  both  balance  changes  (Am_bal)  and  lot 
controllled  ammunition  (Arn-lot)  [the  many],  the  query  function  was  used  to  fill  a  newly 
created  table  from  which  the  report  was  specified. 

This  chapter  represents  the  first  steps  in  implementing  the  ARM  IRS  relational  de¬ 
sign  in  the  data  model  of  a  specific  microcomputer  DBMS.  Obviously,  there  is  much 
work  remaining  before  ARM1RS  can  be  fully  implemented  as  a  functioning  prototype. 
The  final  chapter  of  this  thesis  suggests  some  promising  areas  for  future  work. 
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VI.  SUGGESTIONS  FOR  FUTURE  STUDY 


A.  DEVELOPMENT  OF  AN  EXPERT  DATABASE  SYSTEM 

Shipboard  ammunition  management,  especially  the  preparation  of  requisitions  and 
transaction  reports,  is  a  very  rule-intensive  process.  Expertise  in  ATR  and  ammuniton 
requisition  drafting  comes  only  after  hours  of  work  using  many  required  references. 
Gradually,  the  Gunnery  Officer  becomes  familiar  with  the  procedures  used  to  draft  these 
documents.  By  the  time  the  user  has  become  familiar  with  the  intricacies  of  this  function, 
the  new  expert  is  often  transferred  to  another  division  or  ship.  After  this  loss  of  corpo¬ 
rate  knowledge,  the  learning  process  begins  again  with  another  officer.  Unless  the 
Weapons  Department  is  fortunate  enough  to  have  a  former  Gunnery  .'Ordnance  Officer 
available  to  share  his  expertise,  preparation  of  ATRs  and  requisitions  will  initially  be 
ineflccient  and  subject  to  errors.  A  computer-based  system  combining  the  ARM  IRS 
database  developed  in  this  thesis  and  an  expert  system  incorporating  the  rules  from  fleet 
ammunition  management  instructions  promises  to  be  a  valuable  aid  in  ATR/requisition 
processing  and  Gunnery  Officer  training. 

Integrating  the  ARM  IRS  database  and  the  fleet  ammunition  management  in¬ 
structions  into  an  expert  database  system  is  the  most  promising  suggested  area  for  fur¬ 
ther  work.  Other  researchers  in  this  field  (Kamel  and  Lekey,  1990)  have  demonstrated 
the  value  and  feasibility  of  such  an  approach  to  create  a  loosely  coupled  system  in  which 
the  database's  integrity  is  maintained  while  an  expert  system  uses  the  data,  its  own  rule 
base,  and  user  input.  The  ARM  IRS  database  could  still  be  used  as  a  stand-alone  inter¬ 
active  system  for  ammunition  management.  As  a  component  in  the  expert  database 
system,  it  would  provide  data  to  an  Ammunition  Management  Expert  System.  For  ex¬ 
ample,  using  ARM  IRS  information  about  the  ship  and  the  ammunition  involved  in  a 
transaction,  the  expert  database  system  would  use  its  rules  to  create  the  ATR  header, 
aiding  in  classification  and  addressing  decisions  essential  to  transaction  report  drafting. 
Appendix  L  describes  the  dialogue  and  rule  base  components  of  just  such  an  expert  da¬ 
tabase  system  for  creating  the  ATR  header. 

As  shown  in  Appendix  L,  the  system  dialogue  consists  of  a  series  of  questions  pre¬ 
sented  to  the  user  as  multiple  choice  menus  and  data  entry  lines.  When  the  expert  da¬ 
tabase  system  is  selected,  the  user  is  prompted  for  answers  to  these  questions. 
Information  from  the  COMMAND  and  AMMO  INVENTORY  (through  TRANS- 
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ACTION)  objects  is  extracted  from  the  database  and  applied  to  the  addressing  and 
classification  rules.  The  resulting  decisions  are  displayed  to  the  user  and  passed  to  the 
TRANSACTION  object  in  the  ARMIRS  database  from  which  an  ATR  can  be  gener¬ 
ated. 

The  rule  base,  also  shown  in  Appendix  L,  is  a  series  of  20  rules  in  the  IF-THEN 
format  used  by  Hayes-Roth  (1985,  pp.  930-934).  This  rule  base  performs  logical  deci¬ 
sions  using  input  from  the  ARMIRS  database  to  help  make  the  classification  and  ad¬ 
dressing  decisions  used  in  the  ATR  header. 

Use  of  an  expert  system  shell  (with  an  expanded  set  of  IF-THEN  rules)  working 
together  with  the  ARMIRS  database  offers  the  promise  of  storing  ammunition  man¬ 
agement  expertise  and  making  this  rule-based  knowledge  available  to  shipboard  person¬ 
nel.  The  development  of  an  expert  database  system  is  the  most  promising  area  for  future 
work. 


r.  OTHER  SUGGESTIONS  FOR  FUTURE  WORK 


This  thesis  represents  only  an  initial  iteration  of  system  development  for  a  prototype 
shipboard  ammunition  management  system.  In  addition  to  work  on  the  expert  database 
system  discussed  above,  the  following  projects  are  suggested: 


1.  Fully  implement  the  ARMIRS  design  (including  security  and  backup  components 
not  designed  in  this  thesis)  with  a  relational  microcomputer  DBMS  software  pack¬ 
age. 

2.  Using  the  testing  theories  of  software  engineering,  develop  a  test  and  evaluation 
plan  to  specify  white-  and  black-box  testing  strategies  for  ARMIRS,  including  the 
development  of  sample  data  sets. 

3.  Using  a  commercially  available  prototype/ demo  software  product  with  "screen- 
grabber"  capability  (i.e.,  PROTEUS,  etc.),  produce  a  "workalike  prototype",  prod¬ 
uct  demonstration,  or  ARMIRS  tutorial.  None  of  these  would  require  full  DBMS 
implementation  (item  1  above)  as  a  prerequisite  and  would  be  an  excellent  vehicle 
for  user  input  for  the  next  design  iteration. 

4.  Select  an  ARMIRS  test  ship,  use  a  functioning  prototype  (from  item  1  above)  to 
run  ARMIRS  in  parallel  with  the  manual  system,  solicit  feedback,  and  report  les¬ 
sons  learned. 


5.  Write  a  ARMIRS  user's  manual  that  would  completely  guide  the  ammunition 
management  (or  computer)  novice  through  system  use. 

6.  Investigate  the  feasibility  of  incorporating  ARMIRS  into  the  Shipboard  Non- 
Tactical  ADP  System  (SNAP)  now  common  on  U.  S.  Navy  ships. 


7.  Analyze  the  issues  in  directly  connecting  ships  to  SPCC's  Navy-wide  CAIMS  da¬ 
tabase  or  the  NOMIS  system  at  weapons  stations.  What  changes  would  be  re¬ 
quired  of  the  ARMIRS  design?  How  could  ARMIRS  interface  with  the  shore 
establishment? 
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8.  Develop  a  bar  code  scanning  module  to  work  with  the  ARMIRS  database  appli¬ 
cation  aboard  ship.  The  system  should  be  compatible  with  the  Fleet  Optical  Scan¬ 
ning  Ammunition  Marking  System  (FOSAMS)  used  in  shore-based  ammuntion 
management  systems. 

9.  Enhance  ARMIRS  functionality  by  proving  for  efficient  bulk  data  initial  entry. 

10.  Use  commercial  form-generation  software  packages  to  reproduce  DD  Form  1348 
and  other  forms  in  a  manner  consistent  with  ARMIRS  database  design  but  not 
limited  to  a  specific  DBMS  implementation  (i.e.,  DBASE,  PARADOX,  etc.). 


APPENDIX  A.  OBJECT  DIAGRAMS 
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REQN  LINE  ITEM 


*NI  IN 

Quantity 

Project  Code 

Media  Status  Code 

Signal  Code 

Demand  Code 

Advice  Code 

Fund  Code 

Urgency  of  Need 

Required  Delivery  Date 

Status 

Classification 
Priority  Code 


REQUISITION 


AMMO  INVENTORY 


Figure  2.  REQN  LINE  ITEM  Object 


AMMO  INVENTORY 


Figure  3. 


*NIIN 

NALC 

FSC 

Short  Title 
COG  Symbol 
Unit  Price 
Sonobouy  Channel 
Shlpflll  Allowance 
Warning  Level 
Mission  Allowance 
Annual  Training  Allowance 
Unit  of  Issue 
CC  Hazmat  Class 
NHEEW 

DOT  Hazmat  Code 
MCC 

Remarks 
Quantity  on  Hand 
Stowage  Location  MV 
Mission  Area  MV 


COMMAND 


REQN  LINE  ITEM 


MV 


TRANSACTION 


MV 


LOT-CONTROLLED  AMMO 


MV 


SERIAL-CONTROLLED  AMMO 


MV 


SERIAL  &  LOT-CONTROLLED  AMMO  MV 


AMMO  INVENTORY  Object 


LOT-CONTROLLED  AMMO 


*Lot  Number 
Stowage  Location  MV 


AMMO  INVENTORY 


TRANSACTION  MV 


SERIAL-CONTROLLED  AMMO 


♦♦Serial  Number 
Malnt.  Due  Date 
Type  of  Malnt.  Due  Code 
Condition 
Stowage  Location 


AMMO  INVENTORY 


TRANSACTION  MV 


SERIAL  &  LOT-CONTROLLED  AMMO 


Figure  4.  LOT  and/or  SERIAL  AMMO  Objects 


TRANSACTION 


*ATR  Serial  Number 

*ATR  Line  Number 

Document  Number 

Jui^n  Date 

Old  Balance 

Quantity  Issued 

Quantity  Received 

Receipt  Code 

Issue  Code 

Loss  Code 

Extended  Price 

Training  Allowance  to  Charge 

Quantity  Experled 

Transaction  Type 

Conslgnee-Consignor  U1C 

Balance  Serviceable 

Balance  Unserviceable 

Training  Allowance  Unexpended 

Quantity  Due  In 

Condition  Code 

Revised  Condition  Code 

Remarks 

Referenced  ATR 

NAR  Serial 

ATR  Class 

ATR  Declass 

ATR  Addressees  MV 


LOT  &  SERIAL-CONTROLLED  AMMO 


APPENDIX  B.  OBJECT  SPECIFICATIONS 


A.  OBJECT  DEFINITIONS 

1.  COMMAND  Object 

•  *UIC;  Unit-identification-codes 

•  Name;  Navy-command-names 

•  Hull  Number;  Hull-numbers 

•  Service  Designation  Code;  Service-designation-codes 

•  Location;  Mailing-addresses 

•  FAD;  Force-activity-designators 

•  Fleet;  Logistics-commanders 

•  Activity  Classification  Code;  Activity-classification-codes 

•  REQUISITION  MV;  REQUISITION  object 

•  AMMO  INVENTORY  MV;  AMMO  INVENTORY  object 

2.  REQUISITION  Object 

•  "‘Document  Number;  Document-numbers 

•  Document  Identifier;  Document-identifiers 

•  Classification;  Security-classifications 

•  Reqn  Declas;  Declas-dates 

•  Remarks;  Remarks 

•  Addressees  MV;  Navy-command-names 

•  COMMAND;  COMMAND  object 

•  COMMAND;  COMMAND  object  SUBSET  [UIC,  Name,  Location]  14 

•  REQN  LINE  ITEM  MV;  REQN  LINE  ITEM  object 

3.  REQN  LINE  ITEM  Object 

•  "'NUN;  National-item-identification-numbers 

•  Quantity;  Reqn-qty 

14  Note  that  the  COMMAND  object  occurs  twice  in  the  REQUISITION  Object.  The  first 
occurence  is  for  the  ship  sending  the  requisition  (the  ship  of  interest  for  ARMIRS  purposes).  The 
second  occurence  is  for  the  ship  or  weapons  station  filling  the  requisition.  In  the  latter  case,  only 
a  subset  of  the  COMMAND  object  properties  is  needed  for  the  requisition. 


51 


Project  Code;  Project-codes 

Media  Status  Code;  Media-status-codes 

Signal  Code;  Signal-codes 

Demand  Code;  Demand-codes 

Advice  Code;  Advice-codes 

Fund  Code;  Fund-codes 

Urgency  of  Need;  Need-urgencies 

Required  Delivery  Date;  Required-delivery-dates 

Status;  Reqn-status 

Classification;  Security-classifications 

Priority  Code;  Priority-codes 

REQUISITION;  REQUISITION  object 

AMMO  INVENTORY;  AMMO  INVENTORY  object 

4.  AMMO  INVENTORY  Object 
*NIIN;  National-item-identification-numbers 
NALC;  Navy-ammunition-logistics-codes 
FSC;  Federal-supply-codes 
Short  Title;  Nomenclature 
COG  Symbol;  Material-cognizance-symbols 
Unit  Price;  Money 

Sonobouy  Channel;  Sonobouy-channels 

Shipfill  Allowance;  Shipfill-allowances 

Mission  Allowance;  Mission-allowances 

Annual  Training  Allowance;  NCEA-training-allowances 

Unit  oflssue;  Units-of-issue 

Stowage  Location  MV;  Shipboard-magazines-and-lockers 
CG  Hazmat.  Class;  USCG-hazardous-material-classifications 
Activity  Classification  Code;  Activity-classification-codes 
NHEEW;  Net-explosive- weights 

DOT  Hazmat.  Code;  DOT-hazardous-material-classifications 
MCC;  Material-control-codes 
Remarks;  Remarks 
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•  Warning  Level;  Low-stock-warning-levels 

•  Quantity  on  Hand;  Onboard-totals 

•  Mission  Area  MV;  Mission-areas 

•  REQN  LINE  ITEM  MV;  REQN  LINE  ITEM  object  SUBSET  [NALC,  NUN, 
Quantity];  REQUISITION  object  SUBSET  [Document  Number] 

•  COMMAND;  COMMAND  object  SUBSET  [UIC,  Name,  Hull  Number] 

•  TRANSACTION  MV;  TRANSACTION  object 

•  LOT  CONTROLLED  AMMO  MV;  LOT  CONTROLLED  AMMO  object 

•  SERIAL  CONTROLLED  AMMO  MV;  SERIAL  CONTROLLED  AMMO  object 

•  SERIAL  &  LOT  CONTROLLED  AMMO  MV;  SERIAL  &  LOT  CON¬ 
TROLLED  AMMO  object 

5.  LOT  CONTROLLED  AMMO  Object 

•  ’"Lot-Number;  Lot-numbers 

•  Stowage  Location  MV;  Shipboard-magazines-and-lockers 

•  AMMO  INVENTORY;  AMMO  INVENTORY  object 

•  TRANSACTION  MV;  TRANSACTION  object 

6.  SERIAL  CONTROLLED  AMMO  Object 

•  -  Serial  Number;  Serial-numbers 

•  Maint.  Due  Date;  Maint-due-dates 

•  Type  of  Maint.  Due  Code;  Maint-due-types 

•  Condition;  Conditions 

•  Stowage  Location;  Shipboard-magazines-and-lockers 

•  AMMO  INVENTORY;  AMMO  INVENTORY  object 

•  TRANSACTION  MV;  TRANSACTION  object 

7.  SERIAL  &  LOT  CONTROLLED  AMMO  Object 

•  *Lot  Number;  Lot-numbers 

•  ^Serial  Number;  Serial-numbers 

•  Maint.  Due  Date;  Maint-due-dates 

•  Type  of  Maint.  Due  Code;  Maint-due-types 

•  Condition;  Conditions 

•  Stowage  Location;  Shipboard-magazines-and-lockers 

•  AMMO  INVENTORY;  AMMO  INVENTORY  object 


53 


•  TRANSACTION  MV;  TRANSACTION  object 


8.  TRANSACTION  Object 

•  *ATR  Serial  Number;  ATR-serial-numbers 

•  *ATR  Line  Number;  ATR-line-numbers 

•  Document  Number;  Document-numbers 

•  Julian  Date;  Julian-dates 

•  Old  Balance;  Old-balances 

•  Quantity  Issued;  Issued-qty 

•  Quantity  Received;  Received-qty 

•  Receipt  Code;  Receipt-codes 

•  Issue  Code;  Issue-codes 

•  Loss  Code;  Loss-codes 

•  Extended  Price;  Money 

•  Training  Allowance  to  Charge;  Unit-idcntification-codes 

•  Quantity  Expended;  Expended-qty 

•  Transaction  Type;  Transaction-types 

•  Consignee  or  Consignor  U1C;  Unit-identification-codes 

•  Balance  Serviceable;  Serviceable-balances 

•  Balance  Unserviceable;  Unserviceable-balances 

•  Training  Allowance  Unexpended;  NCEA-remaining 

•  Quantity  Due  In;  Due-in-qty 

•  Condition  Code;  Condition-codes 

•  Revised  Condition  Code;  Condition-codes 

•  Remarks;  Remarks 

•  Referenced  ATR;  ATR-serial-numbers 

•  NAR  serial;  NAR-serial-numbers 

•  ATR  Class;  Security-classifications 

•  ATR  Declas;  Declas-dates 

•  ATR  Addressees  MV;  Navy-command-names 

•  AMMO  INVENTORY;  AMMO  INVENTORY  object 

•  LOT  CONTROLLED  AMMO;  LOT  CONTROLLED  AMMO  object,  or 

•  SERIAL  CONTROLLED  AMMO;  SERIAL  CONTROLLED  AMMO  object,  or 
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•  SERIAL  &  LOT  CONTROLLED  AMMO;  SERIAL  &  LOT  CONTROLLED 
AMMO  object 

B.  DOMAIN  DEFINITIONS 

( 1)  Activity-classification-codes 

•  Alphabetic  1 

•  Code  (from  SPCCINST,  1988,  p.  S-5-D1)  indicating  the  intended  use  of  ammuni¬ 
tion  stocks  carried  by  a  command. 

•  ARM  IRS  default  is  [A],  indicating  use  on  combatant  ships  and  submarines. 

(2)  Advice-codes 

•  Text  2 

•  Code  from  requisition  originators  to  initial  processing  points  to  provide  coded  in¬ 
structions  to  supply  sources. 

(3)  AT R-line-numbers 

•  Numeric  2 

•  Indicate  position  of  a  transaction  line  item  on  an  Ammunition  Transaction  Report. 

f4)  A  TR-serial-numbers 

•  Numeric  3 

•  Serial  number  locally  assigned  to  an  Ammunition  Transaction  Report.  Restarts  at 
001  after  reaching  999. 

( 5)  Conditions 

•  Text  1 

•  ARM  IRS  code  indicating  ammunition  condition  either  as  serviceable  [S]  or  un¬ 
serviceable  [LTj. 

( 6)  Condition-codes 

•  Alphabetic  1 

•  Code  (from  SPCCINST  S010.12D,  1988.  p.  1-2-Cl)  for  classifying  ammunition  in 
terms  of  readiness  for  issue  and  use,  or  to  identify  action  underway  to  change  the 
status  of  the  material. 

•  ARM  IRS  default  is  [A],  indicating  fully  serviceable  ammunition. 

(7)  Declas-dates 
»  Text  7,  mask  NNAAANN 

•  Where  NN  is  numeric,  AAA  is  alphabetic  [JAN. ..DEC],  and  NN  is  numeric. 

•  The  date  a  classified  message  is  to  be  declassified  (e.g.,  29APR59). 
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f  8)  Demand-codes 


•  Text  1 

•  Indicates  whether  the  demand  for  a  requisitioned  item  is  recurring  [R]  (ARM IRS 
default)  or  non-recurring  [NJ. 

( 9)  Document-identifiers 

•  Text  3 

•  Code  (from  SPCCINST  8010.1 2D,  198S,  p.  8-2-6)  to  indicate  the  purpose  of  doc¬ 
ument  (i.e.,  requisition,  cancellation,  follow-up,  etc.) 

(10)  Document-numbers 

•  Text  14,  mask  TNNNNNNNNNNNNN, 

•  Where  TNNN'N'N  is  the  LTC,  NNNN  is  the  julian  date,  NNNN  is  serial  number. 

•  Identifies  a  requisition  or  turn-in  document. 

(11)  DOT-hazardous-material-classfications 

•  Text  2 

•  Code  assigned  by  the  Department  of  Transportation  to  indicate  the  type  of  hazard 
involved  when  shipping  ammunition. 

( 12)  Due-in-qty 

•  Numeric  5 

•  Requisitioned  quantity  still  outstanding.  Represents  the  unfilled  balance  of  a 
requistion. 

(13)  Expended-qty 

•  Numeric  5 

•  Quantity  of  ammunition  reduced  from  inventory  by  means  other  than  transfer  or 
condition  code  change. 

(14)  Federal-supply-codes 

•  Numeric  4 

•  Code  used  with  NUN'  or  N'ALC  for  ammunition  identification. 

( 15)  Force-activity-designators 

•  Numeric  1 

•  Number  [1-5]  assigned  to  a  command  from  NAVSUP  Pub  485,  sections  3045-3049 
to  reflect  operational  readiness  and  used  (with  Urgency  of  Need  Code)  to  assign  a 
requisition  priority. 
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( 16)  Fund-codes 

•  Text  2,  mask  T6, 

•  Where  T  is  text  [cither  2  or  Y]  and  6  is  the  numeral  six. 

•  Code  used  to  cite  accounting  data  on  requisitions. 

•  Fleet  units  use  fund  code  Y6  (ARM IRS  default)  and  shore  units  use  fund  code  26. 

(17)  Hull-numbers 

•  Text  8 

•  Hull  number  assigned  to  a  commissioned  naval  vessel  (e.g.,  FF1071,  SSN685). 

( 18)  Issue-codes 

•  Text  6 

•  Code  (from  SPCCINST  8010.12D,  1988,  p.  8-5-H1)  indicating  how  ammunition 
was  issued  from  inventory  to  another  command. 

(19)  Issued-qty 

•  Numeric  5 

•  Quantity  transferred  from  a  command  resulting  in  an  inventor}’  quantity  decrease. 

(20)  Julian-daies 

•  Numeric  4,  mask  YDDD, 

•  Where  Y  is  the  last  digit  of  the  year  [0-9]  and  DDD  is  the  number  assigned  to  the 
day  [001-366). 

•  Date  of  an  event  or  document  consisting  of  the  units  digit  of  the  year  and  a  three 
digit  expression  of  the  numeric  equivalent  of  the  day  of  the  year  (e.g.,  9004  is  04 
JAN  1989). 

(21)  Logistics-commanders 

•  Alphabetic  4 

•  The  Fleet  CIXC  having  authority  over  a  unit's  ammunition  logistics  reporting. 

•  Commands  under  CIXCPACFLT  use  [PAC]  while  units  under  CIXCLAXTFLT 
use  [LANT]. 

(22)  Loss-codes 

•  Alphabetic  5 

•  Code  (from  SPCCINST  8010.12D,  1988,  p.  8-5-11)  indicating  how  ammunition  was 
lost  from  inventory  (i.e.,  through  physical  count,  by  accounting  error,  by  theft,  etc.) 
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(23)  Lot-numbers 


•  Text  16 

•  A  number  assigned  at  the  time  of  manufacture  to  a  group  of  ammunition  rounds, 
each  component  of  which  is  produced  by  one  manufacturer  under  uniform  condi¬ 
tions  and  which  is  expected  to  perform  in  a  uniform  way. 

( 24)  Low-stock-warning-levels 

•  Numeric  2  [.01-.99] 

•  Stock  level  (expressed  as  a  percentage  of  allowance)  where  the  user  is  warned  of  a 
low  stock  condition. 

(  25  }  M ailing-address 

•  Text  30 

•  Location  of  an  ammuntion  transaction  or  a  requested  deliver}’  location  (e.g., 
CONCORD  CA  or  PEARL  HARBOR  HI). 

(26)  Maint-due-dates 

•  Text  3,  mask  MYY, 

•  Where  M  is  the  month  (1-9,0,N,D]  and  YY  is  the  last  two  digits  of  the  year. 

•  The  month  and  year  (e.g.,  N90  is  NOV  1990)  of  the  next  scheduled  maintenance 
on  items  with  serial  numbers  serial  numbers. 

(27)  M aint-due-iypes 

•  Alphabetic  1 

•  Indicates  the  tvpe  of  periodic  maintenance  required  for  torpedoes  and  air-launched 
missiles  from  SPCCINST  S010.12D  (1988,  p.S-5-Bl). 

(  28  )  Mi aterial-cognizance-symbols 

•  Text  2,  mask  N'A, 

•  Where  X  is  a  number  and  A  is  a  letter. 

•  Indicates  the  Inventor}’  Control  Point,  office,  or  agency  which  exercises  supply 
management  responsibility  for  an  item. 

•  Allowed  values  for  conventional  ammunition  are  0T,  2D,  2E,  2T,  4E,  4T,  6T,  8E, 
8S,  ST,  and  SU. 

(29)  Material-control-codes 

•  Alphabetic  1 

•  Code  assigned  by  the  Inventor}’  Manager  to  indicate  to  field  activities  that  special 
reporting  or  control  requirements  may  be  necessary.  Indicates  a  serial/lot  tracked 
item. 
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(30)  Media-status-codes 


•  Text  1 

•  Code  used  in  requisitions  to  indicate  the  type  of  supply  status  required  and  the 
method  by  which  it  is  to  be  furnished. 

(31)  Mission-allowances 

•  Numeric  5 

•  The  quantity  of  ammunition  above  and  beyond  shipfill  allowance  for  use  on  a 
specific  mission. 

(32)  M  ission-areasl  5 

•  Alphabetic  4 

•  Combat  mission  area(s)  associated  with  an  ammunition  type. 

•  Allowed  values  are  [ASUW,  ASW,  AAW,  AMW  (for  amphibious  warfare),  and 
MIW  (for  mine  warfare)]  as  described  in  NWP-7. 

•  Used  in  SORTS  readiness  repoit  input  to  the  Operations  Department. 

( 33)  Money 

•  Text  13,  mask  XN,NNX,NNX.NN 

•  Where  X  is  numeric  and  a  leading  dollar  sign  is  not  used. 

•  Used  for  prices  on  turn-in  documents. 

(34)  A'/l  R-serial-numbers 

•  Numeric  5,  mask  YYNNX, 

•  Where  YY  indicates  the  year  and  NNN  indicates  the  serial  number. 

•  Assigned  to  Notices  of  Ammunition  Reclassification. 

(  35  )  Xational-item-identification-numbers 

•  Text  9 

•  A  stock  number  assigned  by  the  Defense  Logistics  Services  Center  to  each  item  in 
the  Federal  Cataloging  Program. 

(  36 )  h'avy-ammunit  ion-logistics-codes 

•  Text  4 

•  Code  assigned  to  ammunition  groups  by  SPCC. 


15  LCDR  Carl  A.  Carpenter,  U’SN  contributed  useful  insights  on  the  Operations  Department 
view  of  ammunition  inventory  data. 


I. 
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(37)  Navy-command-names 

•  Text  30 

•  Name  of  a  command  as  listed  in  the  Plain  Language  Address  Director}'. 

(38)  NCEA-remaining 

•  Numeric  5 

•  The  quantity  of  ammunition  with  a  training  allowance  available  for  expenditure  in 
the  current  fiscal  year. 

(39)  NCEA-training-allowances 

•  Numeric  5 

•  The  quantity  of  a  particular  ammunition  item  authorized  for  expenditure  in  a  fiscal 
year  for  training.  Promulgated  in  the  30000  series  NAVSEA  Shipfill  Allowance 
List. 


( 40)  Need-urgencies 

•  Alphabetic  1 

•  Letter  code  [A,  B,  or  C]  designating  the  impact  on  mission  readiness  if  a  requisition 
is  not  received  by  the  lequired  delivery  date.  Used  with  Force  Activity  Designator 
to  give  a  requisition's  priority. 

(41)  Net-explosive-weighis 

•  Text  10 

•  Total  weight  of  explosive  components  of  a  device.  Expressed  in  whole  numbers 
with  the  units  (i.e.,  20  LBS,  30  KG). 

(  42  )  Nomenclature 

•  Text  20 

•  Short  text  description  of  ammunition  consisting  of  noun  name  and  MK/MOD 
from  NAVSEA  TW010-AA-ORD-010. 

(43)  Old-balances 

•  Numeric  5 

•  The  inventor}'  balance  prior  to  a  transaction  or  the  balance  brought  forward  to  a 
new  inventor}'  record. 

(44)  Onboard-totals 

•  Numeric  5 

•  The  total  quantity  onboard  for  a  particular  NIIN,  regardless  of  condition. 
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(45)  Priority-codes 

•  Numeric  2 

•  Code  expressing  the  relationship  between  COMMAND. FAD  and  REQN  LINE 
ITEM.Urgency  of  Need  to  represent  the  priority  assigned  to  a  requisition. 

( 46)  Project-codes 

•  Text  3 

•  Code  assigned  to  a  specific  project  by  DoD.  Used  on  requisitions  for  recognition 
throughout  the  distribution  system. 

(47)  Receipt-codes 

•  Text  6 

•  Code  (from  SPCCINST  8010. 1 2D,  1988,  p.  8-5-G1)  indicating  how  the  material 
was  added  to  the  command's  inventory. 

(48)  Received-qty 

•  Numeric  5 

•  Quantity  of  ammunition  received  and  added  to  the  inventory. 

( 49)  Remarks 

•  Text  30 

•  Text  used  for  adding  comments  and  references  where  desired. 

^  50)  Reqn-qty 

•  Numeric  5 

•  Quantity  of  an  ammunition  item  requisitioned. 

*51 )  Reqn-status 

•  Alphabetic  1,  mask  [U,P,F,C] 

•  ARM  IRS  code  indicating  the  status  of  a  requisition  line  item  where  (UJ  =  unfilled, 
[P]  =  partial,  [F]  =  filled,  and  [C]  =  cancelled. 

( 52)  Required-delivery-dates 

•  Text  3 

•  Three-digit  Julian  date  [1-366]  indicating  the  date  required  for  receipt  of  requisi¬ 
tioned  ammunition. 

(53)  Security-classifications 

•  Alphabetic  1 
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•  Code  indicating  security  classification  of  a  requisition,  transaction  report,  or  other 
message  (or  part  of  any  message). 

•  Unclassified  is  indicated  [U]  (ARM IRS  default)  and  Confidential  is  indicated  by 
[C].  Secret  and  Top  Secret  are  not  used  for  conventional  ammunition  messages. 

(54)  Serial-numbers 

•  Text  16 

•  An  identification  number  given  to  an  single  ammunition  round. 

(55)  Service-designation-codes 

•  Text  1 

•  Code  designating  a  military  service  or  part  of  one  of  the  uniformed  services. 

(  56  )  Serviceable-balances 

•  Numeric  5 

•  Quantity  of  ammunition  available  for  use. 

( 57)  Shipboard-magazines-and-lockers 

•  Text  12 

•  Compartment  number  of  ammunition  storage  location. 

(58)  Shipfill-allowances 

•  Numeric  5 

•  Ammunition  quantity  computed  for  allowance  requirements  during  provisioning. 

(59)  Signal-codes 

•  Text  1 

•  Code  on  requisition  indicating  consignee  (ship  to)  and  the  activity  to  receive  the 
bill  (bill  to). 

(60)  Sonobouy-channels 

•  Numeric  2 

•  Indicates  the  preset  channel  on  certain  sonobouys. 

(61)  Transaction-type 

•  Text  2 

•  Code  (from  SPCCINST  8010.32D,  1988,  p.  S-5-F1)  indicating  the  type  of  trans¬ 
action  (i.e.,  receipt,  issue,  adjustment,  inventory  loss,  etc.). 
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(62)  Unit-identification-codes 

•  Numeric  5 

•  Code  which  identifies  a  command. 

( 63)  Units-of-issue 

•  Alphabetic  2 

•  Abbreviation  representing  a  quantity  and  serving  as  a  unit  of  measurement  when 
issuing  ammunition  (e.g.,  BX,  EA,  CA). 

( 64)  Unserviceable-balances 

•  Numeric  5 

•  Quantity  of  ammunition  unavailable  for  use  due  to  condition  code. 

(  65)  USCG-hazardous-material-classif cations 

•  Text  4 

•  Classification  codes  of  hazardous  munitions  as  determined  by  the  U.S.  Coast 
Guard  and  found  in  NAVSEA  OP  2165,  Vol.  2.  This  code  determines  how  ammu¬ 
nition  is  loaded  aboard  ship. 
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APPENDIX  C.  DATAFLOW  ANALYSIS 


64 


65 


66 


Figure  8.  Process  1  (Manage  Inventory)  Diagram 
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Figure  9.  Process  2  (Generate  Requisitions/Turn-ins)  Diagram 
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Figure  ID.  Process  3  (Generate  Reports)  Diagram 
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APPENDIX  D.  SAMPLE  FORMS 
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Figure  12.  COMMAND  Information  Form 
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Figure  13 


•# 

♦ 

•It 

* 

ft 

♦ 

* 

CO 

»• 

ft  D 

♦ 

•H 

z  * 

♦ 

•It 

ft 

a 

♦ 

•H 

<  * 

♦ 

-It 

z 

•It 

u 

♦ 

* 

ft 

* 

a: 

•* 

Eh 

♦ 

o 

* 

* 

z  o 

« 

-It 

♦ 

* 

* 

* 

^  > 

* 

♦ 

ft 

* 

♦ 

♦ 

• 

«<  CO 

♦ 

* 

< 

« 

•  • 

* 

« 

II 

z 

♦ 

♦ 

ft 

•* 

H 

♦ 

s 

ft  P 

♦ 

«t 

♦ 

* 

•It 

D 

•  • 

* 

ft 

<  * 

♦ 

* 

* 

u 

♦ 

o 

* 

* 

ft  -It 

♦ 

* 

•* 

a 

* 

o 

O 

* 

♦ 

O  -It 

♦ 

♦ 

O 

< 

* 

Eh 

ft  > 

♦ 

♦ 

z  * 

♦ 

-It 

o 

* 

CO 

CO 

«t 

♦ 

, 

« 

z 

* 

* 

* 

♦ 

z  * 

-n 

-It 

♦ 

* 

2 

o  * 

-n 

•It 

♦ 

♦ 

•  • 

Q 

ft 

* 

♦ 

CO  * 

♦ 

-It 

•• 

♦ 

ft 

3 

♦ 

« 

Z  -It 

* 

♦ 

o 

* 

o 

t 

z 

♦ 

♦ 

U  -It 

-it 

♦ 

5 

♦ 

H 

* 

♦ 

♦ 

•it 

* 

o 

♦ 

ft 

a  2 

♦ 

♦ 

< 

♦ 

♦ 

* 

ft 

ft 

ft  -It 

♦ 

« 

* 

* 

z  z 

« 

♦ 

O  «t 

* 

♦ 

♦ 

« 

Eh 

Z  -It 

«* 

« 

* 

♦ 

H 

o  q 

* 

♦ 

♦ 

« 

♦ 

z 

ft 

♦ 

♦ 

O  -It 

« 

♦ 

* 

p 

a  o 

X  «t 

♦ 

♦ 

* 

M 

* 

* 

o 

o 

-It 

♦ 

z 

♦ 

cu 

* 

* 

z 

♦ 

* 

« 

♦ 

o 

* 

X 

♦ 

* 

H 

♦ 

♦ 

♦ 

Q 

* 

H 

« 

* 

u 

♦ 

-It 

Eh 

« 

* 

•  * 

ft 

♦ 

Eh 

♦ 

•* 

♦ 

♦ 

ft 

ft  -It 

♦ 

X 

O 

* 

< 

♦ 

♦ 

X 

O 

a  * 

-it 

w 

O 

* 

O 

♦ 

♦ 

ft 

i  a 

* 

« 

ft 

H  * 

« 

ft 

w 

* 

Q 

* 

♦ 

o 

i  > 

* 

* 

ft 

ft  -it 

-it 

ft 

♦ 

3 

« 

•• 

Eh 

x  a 

♦ 

-It 

ft 

ft  ♦ 

•it 

* 

♦ 

ft  CO 

ft 

« 

-It 

♦ 

•it 

•It 

•It 

♦ 

ft 

♦ 

♦ 

♦ 

a  h 

H 

* 

* 

Q  •* 

♦ 

* 

* 

•It 

o 

* 

* 

Z  X 

z 

Eh  -It 

* 

♦ 

-It 

¥ 

o 

* 

* 

•  • 

< 

cxco 

♦ 

♦ 

o 

X  -It 

-it 

* 

♦ 

•It 

H 

* 

« 

2 

3 

ft 

1  CO 

♦ 

* 

H 

ft  * 

♦ 

* 

•It 

•It 

co 

•* 

♦ 

ft 

<  V 

1  H 

* 

♦ 

Eh 

♦ 

•It 

•It 

w 

•  • 

ft 

ft  o 

♦ 

-It 

a 

-It 

-it 

4t 

•It 

-It 

ft 

x 

< 

X 

Eh 

♦ 

« 

< 

♦ 

« 

-It 

•It 

w 

< 

'  w 

z 

H  CO 

CO 

1 

CO  * 

« 

« 

•It 

•It 

Eh 

z 

a 

Z 

ft 

♦ 

* 

z 

1 

CO  « 

♦ 

* 

* 

•It 

CO 

♦ 

z 

•It 

ft 

ft 

♦ 

♦ 

2 

1 

Q  * 

-it 

« 

♦ 

♦ 

£5 

♦ 

* 

♦ 

ft 

«t 

•It 

ft 

1 

3  * 

♦ 

•It 

•It 

X 

♦ 

* 

ft 

ft 

* 

* 

Eh 

1 

♦ 

-It 

•H 

♦ 

* 

•  * 

D 

♦ 

-It 

CO 

* 

-K 

-It 

-It 

♦ 

* 

* 

h 

a 

ft 

« 

•It 

♦ 

-It 

-It 

* 

* 

o 

♦ 

♦ 

ft  ft  -It 

-It 

-It 

•It 

•It 

♦ 

•• 

Q 

« 

♦ 

D  * 

•It 

♦ 

•It 

•It 

* 

z 

-It 

♦ 

Q  CO  -It 

•It 

« 

-It 

•It 

♦ 

o 

♦ 

-It 

-It 

CO  -It 

-It 

« 

•It 

♦ 

•• 

H 

♦ 

Eh 

* 

* 

O  H 

♦ 

•It 

-It 

z 

CO 

* 

♦ 

♦ 

* 

Z 

-It 

* 

♦ 

•It 

•It 

•It 

4t 

H 

CO 

* 

* 

* 

•* 

ft 

-It 

-It 

O 

* 

-It 

* 

•n 

H 

H 

•  » 

♦ 

♦ 

♦ 

-It 

« 

Eh  -It 

-It 

-It 

-It 

•It 

z 

s 

O 

* 

♦ 

« 

5 

•It 

* 

1 

ft  -It 

-It 

* 

« 

« 

* 

U 

♦ 

* 

♦ 

o 

* 

-H 

1 

O  -It 

« 

« 

-It 

♦ 

* 

•It 

CO 

0 

•It 

♦ 

1 

ft  « 

-It 

•It 

•It 

♦ 

* 

P 

»• 

a 

-It 

•It 

-H 

-It 

•It 

•It 

★ 

CO 

•It 

♦ 

1 

ft  * 

-It 

-It 

•It 

•It 

•  « 

♦ 

•• 

< 

i  w 

♦ 

-It 

o  w  * 

♦ 

-It 

-It 

o 

•  • 

CO 

w 

1  z 

ft  * 

-It 

« 

-It 

•n 

CO 

ft 

ft 

p< 

ft  H 

-It 

•It 

CO 

•• 

ft 

H 

Q 

4 

ft 

♦ 

-It 

CO 

♦ 

X 

0 

Eh 

XV)  « 

*H 

ft 

♦ 

CO 

o 

CO 

<  -It 

•It 

ft 

+ 

z 

<  z 

■It 

-It 

ft  -it 

-It 

CO 

* 

•  • 

Eh 

o 

1  \ 

•K 

* 

a  * 

♦ 

CO 

M 

2 

< 

H 

1  CO 

* 

♦ 

ft  ft  -It 

-It 

ft 

o 

o 

s 

CO 

Q  -It 

•It 

ft 

5 

ft 

N 

CO 

ft 

•It 

-It 

Eh 

♦ 

•It 

Q 

< 

ft 

< 

H 

Eh 

* 

♦ 

CO 

Q 

z 

< 

X 

X 

< 

* 

* 

<  ft 

< 

Q 

-It 

•It 

1 

a  * 

-It 

INVENTORY  and  TRANSACTION  Information  Form 


i 


73 


74 


REQUISITION  INFORMATION 
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APPENDIX  E.  FUNCTIONAL  COMPONENT  DESCRIPTIONS 


A.  MANAGE  INVENTORY  APPLICATION 

1.  Manage  Inventor}'  Update  Mechanisms 
a.  Add  New  COMMAND  Data 

16 

•  Input 

•  U1C.  Name,  Hull  Number,  Fleet,  Service  Code,  Activity  Classification  Code, 
and  Location  (required  only  for  requisitions)  of  the  ARMIRS  ship. 

■  UIC,  Name,  Hull  Number  (N/A  for  shore  commands),  Service  Code,  Activity 
Classification  Code,  and  Location  (required  only  for  requisitions  or  turn-ins)  of 
the  other  unit,  if  any,  involved  in  an  inventor}'  action. 

•  Output 

■  New  COMMAND  object  instance 

■  Confirmation  message  on  screen 

•  Processing  Notes 

■  There  may  not  be  information  on  another  command  to  enter  if  the  system  is 
newly  installed  and  has  not  yet  been  used  for  a  transaction  involving  another 
command. 

■  The  location  and  fleet  of  the  ARMIRS  ship  may  change,  but  the  other  ship  in¬ 
formation  is  static. 

■  There  is  not  always  another  unit  involved  in  a  reportable  action.  For  example, 
the  system  does  not  make  any  use  of  information  on  another  command  for  a 
transaction  involving  an  ammunition  expenditure  (e.g.,  loss,  firing,  etc). 

«  Volume  17 

■  Once  for  ARMIRS  ship  static  information. 

■  14  times  per  year  for  information  on  the  participating  unit. 

•  Frequency 

■  Monthly  (as  information  changes) 


16  Functionally  part  of  the  inventory  management  process  but  selected  by  the  user  from  a 
separate  menu. 

1 7  Volumes  and  frequencies  are  (maximum;  estimates  for  Knox  class  frigates,  a  typical  smaller 
combatant  ship.  Values  for  other  platforms  may  vary.  Volumes  and  frequencies  are  highly  de¬ 
pendent  on  a  ship's  operating  schedule. 
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b.  Edit  COMMAND  Data 


•  Input 

■  Correction  information  on  own  ship  or  other  unit  as  provided  by  Gunnery  Of¬ 
ficer  based  on  information  tied  to  major  ship  movements. 

•  Output 

•  Modified  COMMAND  object  instance(s) 

■  Confirmation  message  on  screen 

•  Processing  Notes 

“  This  function  changes  basic  command  and  location  data  to  update  the  COM¬ 
MAND  object. 

•  There  are  no  multiple  presentations  of  this  screen  for  the  user  to  page  through. 
New  information  is  simply  typed  over  the  outdated  information  on  the  form 
(Figure  12)  and  the  update  is  processed. 

■  A  history  of  COMMAND  Information  Forms  is  not  required.  Only  one  form 
is  required  and  that  form  is  updated  as  changes  occur. 

•  Volume 

»  14  times  per  year. 

•  Frequency 

■  Monthly  (as  information  changes) 

c.  Add  a  New  Stock  Record 

•  Input 

■  Ammunition  received  onboard  for  which  a  stock  record  does  not  already  exist. 

■  NA'LC,  FSC,  NIIN,  N".re,  COG,  MCC,  and  Sonobouy  Channel  from  the 
markings  on  the  ammun.  on,  markings  on  the  shipping  container,  or  from  the 
DD  Form  134S  which  accompanies  the  r  "/loaded  ammunition. 

■  Shipfill  and  NCEA  Allowances  from  allowance  lists  held  by  the  ship. 

■  Unit  Price,  NHEEW,  DOT  and  USCG  I-Iazmat  codes  from  NAVSEA  publica¬ 
tion  TWO  10-AA-ORD-10  held  onboard. 

■  Shipboard  location  (for  non-SLIT-controlled  it. ms)  from  the  Gunnery  Officer 
or  Chief  Gunner's  Mate  in  accordance  with  the  ship's  lor  hng  plan. 

•  Defined  low  stock  level  as  determined  by  the  Weapons  Officei. 

■  Combat  mission  area(s)  supported  by  this  item  from  the  Weapons  Officer  (after 
liason  with  the  Operations  Officer). 

•  Output 

■  New  AMMO  INVENTORY  object  instance 

■  Confirmation  message  on  screen 
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•  Processing  Notes 

■  User  may  not  have  all  the  available  information  at  the  time  of  inital  entry  (e.g., 
receipt  of  a  new  N'ALC  for  which  Operations  and  Weapons  Department  Heads 
have  not  defined  the  mission  area(s)  supported)  and  later  editing  may  be  re¬ 
quired  when  all  the  information  has  been  collected. 

«  Equivalent  action  in  the  manual  system  would  be  to  discover  that  a  Master 
Stock  Record  Card  does  not  exist  for  a  newly  acquired  NIIN,  obtain  a  blank 
card,  complete  the  header  information,  and  file  the  card. 

•  This  action  completes  the  top  section  of  the  form  shown  in  Figure  13. 

•  Volume 

■  Six  times  per  year 

•  Frequency 

■  Bimonthly 

d.  Edit  Descriptive  Data 

•  Input 

■  Correction  information  from  revisions  to:  (1)  allowance  lists,  (2)  the  loading 
plan,  (3)  NAVSEA  Publication  TWO  10-AA-ORD-010  ("The  NALC/NTIN 
Book"),  and  (4)  the  Weapons  Officer's  determination  as  to  low  stock  warning 
levels  and  mission  area(s)  supported. 

»  AMMO  INVENTORY  object  instance 

•  Output 

■  Modi, led  AMMO  INVENTORY  object  instance 

■  Confirmation  message  on  screen 

•  Processing  Notes 

•  This  function  modifies  the  general,  descriptive  (not  quantity)  information  on  a 
particular  NALC  and  NIIN. 

■  Equivalent  in  the  manual  system  to  making  corrections  to  the  non-transaction 
fields  on  the  Master  Stock  Record  Card. 

■  Retrieved  from  the  database  (most  commonly  by  NIIN)  in  a  query  and  edit 
mode  when  changes  are  necessary.  Requires  NIIN  (or  other  property  in  the  top 
section  of  Figure  13)  for  retrieval. 

•  Volume 

■  Four  times  per  year 

•  Frequency 

■  Quarterly 
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e.  Add  (Post)  a  Transaction 

•  Input 

-  AMMO  INVENTORY  object 

»  Balance  change  information  shown  on  the  "Stock  History"  and  "Transaction 
Reporting"  sections  of  Figure  13  entered  by  the  user. 

■  ATR  addressees  from  an  expert  database  system  (see  Chapter  VI)  or  from  user 
input. 

•  Output 

»  Updated  AMMO  INVENTORY  object  (new  total  posted) 

■  New  TRANSACTION  object  instance 

■  Updated  SERIAL  and/or  LOT  CONTROLLED  AMMO  object  instance  (if 
applicable) 

»  Confirmation  message  on  screen 

•  Processing  Notes 

■  Each  change  in  ammunition  inventory,  regardless  of  the  reason,  requires  a  new 
TRANSACTION  instance. 

■  Manual  equivalent  to  this  operation  is  to  make  a  single  line  entry  on  the  trans¬ 
action  history  section  of  the  Master  Stock  Record  Card  in  preparation  for 
drafting  an  ATR. 

■  If  a  serial  number  or  lot  number  exists  for  a  NIIN,  the  Serial/Lot  Record  is  also 
updated. 

■  The  total  quantity  on  hand,  regardless  of  condition,  is  update  to  the  AMMO 
INVENTORY  (NIIN)  record  when  the  transaction  is  posted  (automatically  in 
ARM  IRS). 

■  User  must  assign  the  next  sequential  ATR  serial  number  (from  the  ATR  Log) 
to  each  instance. 

■  Document  Number  is  required  only  for  receipt  and  turn-in  transactions.  It  is 
obtained  from  the  DD  Form  1348  accompannnying  the  ammunition  (receipt) 
or  assigned  by  the  user  (turn-in). 

•  Volume 

■  60  per  year,  with  most  of  the  transactions  occuring  in  two  or  three  major 
onloads  offloads  per  year. 

■  Peak  activity  before  or  after  deployments  and  overhauls. 

•  Frequency 

»  Weekly 
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/.  Edit  Transaction  Data 

•  Input 

■  TRANSACTION  object  instance 

■  ATR  Serial  Number  and  Line  Number  from  the  user 

■  Revised  transaction  data  from  the  user 

•  Output 

■  Modified  TRANSACTION  object  instance 

■  Updated  SERIAL  and/or  LOT  CONTROLLED  AMMO  object  instance  (if 
applicable) 

■  Confirmation  message  on  screen 

•  Processing  Notes 

■  Used  to  correct  typographical  errors  on  a  TRANSACTION  instance  already 
added  to  the  database. 

■  To  change  the  meaning  of  a  TRANSACTION  instance  on  a  transaction  for 
which  an  ATR  has  already  been  transmitted,  a  new  instance  (see  preceding 
section)  must  be  created  and  a  new  ATR  generated. 

■  Manual  equivalent  to  this  action  is  correction  (erasure)  of  a  field  on  a  single  line 
in  the  transaction  history  section  of  the  Master  Stock  Record  Card. 

•  Volume 

■  1 6  times  per  year 

•  Frequency 

■  Monthly 

g.  Add  a  New  Serial/ Lot  Record 

•  Input 

■  Serial  Number  and/or  Lot  Number  from  markings  on  the  ammunition,  on  the 
container,  or  on  the  DD  Form  1348  accompanying  the  ammunition. 

■  Maintenance  Date,  Maintenance  Type,  and  Condition  Code  from  the  mainte¬ 
nance  records  accompanying  the  item. 

■  Location  for  shipboard  stowage  from  the  Gunnery'  Officer  or  GMC  in  accord¬ 
ance  with  the  ordnance  loading  plan. 

•  Output 

■  New  SERIAL/LOT  CONTROLLED  AMMO  instance 

■  Confirmation  message  on  screen 

•  Processing  Notes 

■  Entered  on  the  center  section  of  the  Serial/Lot  Information  Form  (Figure  14). 
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■  Requires  a  "parent"  AMMO  INVENTORY  instance  (with  the  NUN*  of  the 
prospective  "child"  lot  or  serial  controlled  item)  already  in  the  database  before 
this  process  can  occur. 

•  Volume 

■  30  times  per  year,  usually  grouped  into  4  major  offload  or  onloads 

•  Frequency 

■  Quarterly 

h.  Edit  Serial! Lot  Information 

•  Input 

■  Correction  to  descriptive  information  on  a  lot  or  serial  ordnance  item,  including 
change  to  Maintenance  Due  Date,  Maintenance  Due  Type,  or  Location. 

•  Output 

.  Modified  LOT  and/or  SERIAL  CONTROLLED  AMMO  instance 

•  Processing  Notes 

■  Condition  Code  (and  Quantity)  are  not  revised  in  this  process.  Those  actions 
require  transaction  reports  and  are  accomplished  through  TRANSACTION. 

■  This  function  accomplishes  the  same  result  for  SLIT-controlled  ammunition  as 
that  performed  by  "AMMO  INVENTORY:  Edit  Descriptive  Data"  (Section 
A-l-d  of  this  Appendix)  for  non-SLIT  ammunition. 

■  Equivalent  action  in  the  manual  system  is  correcting  non-transaction  informa¬ 
tion  on  a  Serial/Location  Card  or  a  Lot/Location  Card. 

■  Records  are  retrieved  from  the  database  in  a  query-by-forms  edit  mode  using  the 
Serial  Number  or  Lot  Number  as  the  basis  for  retrieval. 

•  Volume 

■  Six  per  year 

•  Frequency 

■  Bimonthly 

2.  Manage  Inventory  Display  Mechanisms 
a.  COMMAND  Information  Display 

•  Output  Description 

■  Form  showing  LTC,  Hull  Number  (ships  only),  Command  Name,  Location, 
Activity  Classification  Code,  Fleet,  and  Service  Code  for  the  host  (ARM IRS) 
ship  and  the  other  command  involved  in  a  transaction  or  requisition  (See  Figure 
12). 

•  Source  Data 

■  COMMAND  object 
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Processing  Notes 

■  Since  there  is  only  one  form  representing  both  current  instances  of  the  COM¬ 
MAND  object,  displaying  the  form  is  activated  by  a  menu  selection  and  not  a 
query-by-forms  action  (on  UIC,  etc.). 

■  The  form  is  displayed  prior  to  generating  a  requisition  or  transaction  when  the 
user  finds  the  COMMAND  data  outdated. 

Volume 

■  35  times  per  year 

Frequency 

■  Biweekly 

b.  Stock  Record  Display 

Output  Description 

■  Form  showing  descriptive  data  on  a  NUN  as  shown  in  Figure  13. 

Source  Data 

■  AMMO  INVENTORY  object 

■  AMMO  INVENTORY  property  (commonly  NUN)  keyed  by  user  and  used  as 
the  basis  for  record  retrieval. 

Processing  Notes 

■  If  NIIN  (the  key  attribute  in  AMMO  INVENTORY)  is  used  in  the  display 
query-by-forms  mode,  then  only  one  screen  will  be  available  for  display.  If  the 
user  has  only  the  NALC  or  (worse)  only  the  COG  then  it  will  be  necessary  to 
page  through  a  number  of  screens  until  the  desired  object  instance  is  found. 

■  Equivalent  in  the  manual  system  to  looking  up  a  Master  Stock  Record  Card  in 
a  set  of  cards  filed  by  NALC  and  then  by  NUN. 

Volume 

■  40  per  year 

Frequency 

■  Biweekly 


c.  Stock  History  Display 
Output  Description 

»  Form  showing  the  stock  and  transaction  history  for  a  NUN.  Information  on 
this  form  (Figure  13)  includes  Balance,  Condition  Codes,  Quantity,  New  Bal¬ 
ance  and  other  information  shown  on  the  ATR(s)  for  this  NUN. 

Source  Data 

•  TRANSACTION  object 
■  AMMO  INVENTORY  object 


■  NIIN  (or  other  property  to  use  in  retrieval)  from  user 
Processing  Notes 

■  See  Stock  Record  Display 
Volume 

■  60  per  year 
Frequency 

.  Weekly 

d.  Display  Lot /Serial  Record 
Output  Description 

■  Form  showing  descriptive  data  on  a  serial  or  lot  controlled  item  as  shown  in 
Figure  14. 

Input 

-  SERIAL  CONTROLLED  AMMO  object,  or 

-  LOT  CONTROLLED  AMMO  object,  or 

■  SERIAL  &  LOT  CONTROLLED  AMMO  object 

■  Serial  Number  or  Lot  Number  entered  by  the  user  and  used  as  the  basis  for  re¬ 
cord  retrieval. 

Processing  Notes 

■  Equivalent  in  the  manual  system  to  looking  up  a  Serial/Location  Record  Card 
or  a  Lot.  Location  Record  Card. 

■  If  Serial  Number  or  Lot  Number  (the  key  attributes  in  their  respective  objects) 
are  used  in  the  display  query-by-forms  mode,  then  only  one  screen  will  be  re¬ 
trieved.  However,  if  the  user  knows  only  a  non-key  attribute  (e.g.,  NALC,  COG, 
Location)  then  it  will  be  necessary  to  page  through  a  number  of  screens  until 
the  desired  instance  is  found. 

Volume 

■  50  per  year 
Frequency 

-  Weekly 

3.  Manage  Inventor)’  Control  Mechanisms 

Define  procedures  for  the  Gunnery  or  Weapons  Officer  .to  make  periodic  spot 
checks  on  the  accuracy  of  command,  inventory,  transaction,  and  serial  lot  number 
data.  An  enhancement  to  the  system  could  involve  system  checking  of  data  entries 
(i.e.,  checking  to  ensure  that  LTC  and  Command  Name  match  each  other  from  a 
list  of  Navy  commands). 


System  enhancement  could  include  storage  of  NAVSEA  Publication 
10-TWO-AA-010,  a  large  reference  describing  all  the  available  NIINs  in  the  stock 
system.  ARM  IRS  could  then  check  the  existence  of  information  entered  on  the 
Master  Stock  Record  (e.g.,  checking  validity  of  a  NALC). 

GENERATE  REQUISITIONS  APPLICATION 
1.  Generate  Requisitions  Update  Mechanisms 

a.  Add  a  Requisition 
Input 

■  COMMAND  object 

■  Document  Number,  Document  Identifier,  Requisition  De/Classification,  Ad¬ 
dressees,  and  Remarks  from  user 

•  Line  item  data  including  NALC,  NIIN,  FSC,  Project  Code,  Media/Status  Code, 
Signal  Code,  Demand  Code,  Advice  Code,  Fund  Code,  Priority,  Urgency  of 
Need,  Required  Delivery  Date,  Status,  and  Line  Classification  from  the  user  and 
reference  publications. 

Output 

■  REQUISITION  object  instance 

■  REQN  LINE  ITEM  object  instance(s) 

■  Confirmation  message  on  screen 
Processing  Notes 

■  All  of  the  information  on  the  Requisition  Form  (Figure  15)  must  be  completed 
before  a  requisition  can  be  generated. 

■  An  item  need  not  be  held  in  inventory  to  be  requisitioned. 

■  Initial  (default)  value  for  Requisition  Status  is  [U]  indicating  unfilled. 

Volume 

■  Eight  per  year  (rare  while  deployed),  usually  with  the  majority  of  line  items  on 
two  large  requisitions 

Frequency 

■  Quarterly 

b.  Edit  Requisition  Data 
Input 

■  Update  information  on  a  requisition  as  provided  by  message  or  other  official 
communication.  Requisition  Status  is  almost  always  the  only  requisition  value 
to  change  between  the  time  of  transmission  and  material  receipt. 

Output 

■  Modified  REQN  LINE  ITEM  object  instance 


•  Confirmation  message  on  screen 

•  Processing  Notes 

•  The  form  shown  in  Figure  15  is  retrieved  (by  Document  Number)  in  a  query- 
by-forms  edit  mode.  The  corrections  are  then  entered  by  the  user. 

•  Changing  the  requisition  attributes  (except  for  Requisition  Status  which  does 
not  appear  on  the  transmitted  requisition)  does  not  change  the  transmitted 
requistion.  It  is  necessary  to  modify  or  cancel  a  transmitted  requisition  with  a 
message. 

•  The  purpose  of  this  update  option  is  to  allow  requisition  status  changes  to  be 
made  as  status  messages  are  received. 

■  The  manual  system  equivalent  to  this  process  is  to  write  in  a  new  "Status"  entry 
in  the  Requisition  Log  on  receipt  of  a  requisition  status  message. 

•  Different  line  items  on  the  same  requisition  could  each  have  a  different  status. 
Status  is  given  for  one  line  item. 

•  Volume 

•  15  per  year 

•  Frequency 

■  Monthly 

2.  Generate  Requisitions  Display  Mechanisms 
a.  Single  Requisition  Display 

•  Output  Description 

■  Form  displaying  information  on  a  requisition  (one  Document  Number)  and  all 
of  its  line  items  (Figure  15). 

•  Source  data 

■  REQUISITION  object 

-  REQN  LINE  ITEM  object 

»  Document  Number  entered  by  user 

•  Processing  Notes 

■  Manual  system  equivalent  is  to  look  up  a  requisition  in  the  Requisition  File. 

■  Retrieval  by  NALC  or  NUN  (non-key  attributes  here)  is  also  possible  but  may 
be  more  time  consuming  because  of  multiple  instances. 

•  Volume 

■  1 1  times  per  year 

•  Frequency 

■  Monthly 
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b.  Requisition  Generation 
Output  Description 

■  Report  containing  all  information  required  of  a  requisition  and  its  line  items  as 
shown  in  Figure  15. 

■  Format  for  output  determined  by  user  selection  of  a  desired  format. 

Source  Data 

■  COMMAND  object 

.  REQUISITION  object 

-  REQN  LINE  ITEM  instance(s) 

»  User  selection  of  format  desired  (DD  Form  1348,  DAAS,  or  Naval  Message). 
Processing  Notes 

■  User  selects  a  menu  option  for  the  desired  format. 

■  All  information  on  Figure  15  (except  Status,  which  is  for  internal  use)  must  be 
completed  before  a  requisition  can  be  generated. 

•  Information  on  the  ARM  IRS  ship  and  the  requisitioned  activity  (COMMAND 
object)  must  be  updated  prior  to  generation  of  an  accurate  requisition. 

Volume 

■  1 1  per  year 
Frequency 

■  Monthly 

c.  Turn-In  Document  Generation 
Output  Description 

■  Output  in  DD  Form  1348  format  consisting  of  NUN,  Unit  Of  Issue,  Quantity, 
Document  Number,  COG,  Project  Code,  Unit  Price,  Service  Code,  LTC,  Name, 
Hull  Number,  Extended  Price,  MCC,  DOT  and  USCG  Hazmat  Codes,  Lot  or 
Serial  Number  (if  applicable),  Short  Title,  NAR  Serial  Number  (if  applicable) 

Source  Data 

.  TRANSACTION  object 

-  COMMAND  object 

■  AMMO  INVENTORY  object 

•  SERIAL  and/or  LOT  CONTROLLED  AMMO  object  (if  applicable) 
Processing  Notes 

■  Document  Number  is  locally  assigned  and  must  be  sequentially  issued. 


•  Future  enhancement  to  the  system  would  print  the  boxes  and  columns  of  the 
DD  Form  1348  rather  than  only  providing  formatted  output  that  must  be 
transferred  to  a  DD  Form  1348. 

■  Because  this  function  uses  all  ARMIRS  objects  (except  for  REQN  &  LINE 
ITEM),  all  forms  (except  requisitions)  must  be  updated  prior  to  turn-in  docu¬ 
ment  generation. 

•  Volume 

■  Four  per  year 

•  Frequency 

•  Semiannually 

3.  Generate  Requisitions  Control  Mechanisms 

•  The  system  should  not  allow  assignment  of  duplicate  documents  numbers  or  doc¬ 
ument  numbers  (for  the  ARMIRS  ship)  that  are  out  of  sequence. 

•  Define  procedures  to  allow  the  Weapons  Officer  or  Gunnery  Officer  to  spot  check 
the  accuracy  of  ARMIRS  requisition  data  by  comparing  generated  requisitions  to 
SPCCINST  8010.12D  and  other  instructions. 

C.  GENERATE  REPORTS  APPLICATION 
1.  Generate  Reports  Update  Mechanisms 

None.  Except  for  a  one  field  update  to  TRANSACTION5,  this  is  an  output-only 
function. 


2.  Generate  Reports  Display  Mechanisms 
a.  Requisition  Log  Report 

•  Output  Description 

■  Report  displaying  the  requisitions  issued  by  a  command  with  data  in  columns 
for  Document  Number,  NALC,  Short  Title,  Quantity  Requisitioned,  Required 
Delivery  Date,  Requisition  Status,  and  Priority. 

•  Source  Data 

■  REQUISITION  object 

•  REQN  LINE  ITEM  object 

.  AMMO  INVENTORY  object 

•  Processing  Notes 

■  Rows  consist  of  all  Document  Numbers  where  Required  Deliver)’  Date  exists 
(since  turn-in  documents  [issue  transactions]  also  are  identified  by  document 
numbers  but  never  have  an  RDD). 

■  Rows  are  sorted  by  Document  Number  and  then  by  NUN. 

■  Displays  summary  and  status  information  on  all  requisitions,  regardless  of  sta¬ 
tus. 
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Volume 

•  18  times  per  year 
Frequency 

»  Monthly 

b.  Maintenance  Due  Summary  Report 
Output  Description 

■  Report  summarizing  maintenance  due  information  on  serially  controlled  items 
and  containing  columns  for  NALC,  Short  Title,  Serial  Number,  Maintenance 
Due  Date,  and  Maintenance  Type. 

Source  Data 

-  SERIAL  CONTROLLED  AMMO  object,  or 

-  SERIAL  &  LOT  CONTROLLED  AMMO  object 

-  AMMO  INVENTORY  object 
Processing  Notes 

■  All  ammunition  items  with  serial  numbers  are  displayed  on  this  report. 

■  The  rows  on  the  report  are  sorted  by  NALC  and  then  by  Serial  Number. 

■  Maintenance  Due  Type  may  be  blank  for  some  rows.  Only  torpedoes  and  air- 
launched  missiles  have  a  value  assigned. 

Volume 

■  Four  per  year 
Frequency 

•  Quarterly 

c.  Ship  Ammunition  Listing 
Output  Description 

■  A  report  of  ammunition  held  (without  quantities)  containing  columns  for  COG, 
NALC,  and  Short  Title. 

Source  Data 

-  AMMO  INVENTORY  object 
Processing  Notes 

•  This  report  is  a  list  of  ammunition  types  held  onboard.  It  does  not  include  the 
quantities  found  on  inventory  reports  (See  TRANSACTION  olject). 

■  Equivalent  report  from  the  manual  system  is  processed  by  sorting  through  the 
Master  Stock  Record  Cards  (in  NALC  groups)  and  copying  the  COG,  NALC, 
and  Short  Title  from  the  card  header  information. 


88 


■  Report  rows  are  sorted  by  COG  and  then  by  NALC. 

Volume 

•  16  per  year 
Frequency 

■  Monthly 

d.  Allowance  List  Report 
Output  Description 

■  Columns  for  COG,  NALC,  Short  Title,  Shipfill  Allowance,  and  Training  Al¬ 
lowance  (N'CEA). 

Source  Data 

-  AMMO  INVENTORY  object 
Processing  Notes 

»  This  report  summarizes  the  NAVSEA  (shipfill)  and  NCEA  (training)  allowances 
held  by  the  ship. 

■  Some  NALC/NTIN  items  held  onboard  do  not  have  shipfill  or  training  allow¬ 
ances.  As  a  result,  some  rows  will  have  a  zero  under  the  Shipfill  Allowance 
and  or  Training  Allowance  columns. 

■  The  manual  equivalent  to  this  report  would  be  to  create  a  list  of  NUNs  and  then 
use  the  two  allowance  lists  to  add  allowance  data  for  each  NUN. 

•  Rows  sorted  by  COG,  NALC,  and  then  NUN. 

Volume 

■  Four  per  year 
Frequency 

■  Quarterly 

e.  NAR  Management  Report 
Output  Description 

»  Report  containing  columns  for  NAR  Serial  Number,  NALC,  Short  Title,  Lot 
Number  (if  applicable),  and  Condition  Code. 

Source  Data 

»  AMMO  INVENTORY  object 

•  TRANSACTION  object 

.  LOT  and/or  SERIAL  CONTROLLED  AMMO  objects  (if  applicable) 
Processing  Notes 


■  This  report  is  used  by  the  Gunnery  Officer  to  cross  reference  Notices  of  Am¬ 
munition  Reclassification  with  the  onboard  ammunition  inventory.  It  is  also 
used  to  prevent  missing  N'ARs. 

■  The  only  NTIN's  of  interest  here  are  the  ones  corresponding  to  N’ARS.  This  re¬ 
port  selects  all  NUN'S  where  a  NAR  Serial  Number  exists. 

■  The  instances  on  this  report  are  sorted  by  NAR  Serial  Number,  and  are  there¬ 
fore  in  chronological  order. 

■  Equivalent  in  the  manual  system  to  going  through  the  NAR  File  and  checking 
against  the  Master  Stock  Record  Cards  to  extract  "active"  NARs  refering  to 
ammunition  held  by  the  command. 

•  Volume 

■  16  times  per  year 

•  Frequency 

■  Monthly 

/.  Allowance  Tracking  Report 

•  Output  Description 

■  Report  containing  columns  for  NALC,  Short  Title,  Quantity,  Shipflll  Allow¬ 
ance,  NCEA  Balance  (quantity  unexpended  for  the  current  fiscal  year's 
traininng  allowance),  and  Percent  of  Shipfill  Allowance  onboard. 

•  Source  Data 

-  AMMO  INVENTORY  object 

-  TRANSACTION  object 

•  Processing  Notes 

■  NCEA  Balance  is  calculated  by  adding  all  balance  changes  for  the  fiscal  year 
where  there  is  a  Quantity  Expended  reported.  This  total  is  then  subtracted  from 
the  Training  Allowance  for  that  ammunition  type. 

■  On  01  October  of  each  year,  the  NCEA  Balance  is  set  equal  to  the  ship's 
Training  Allowance. 

■  Percentage  of  Shipfill  Allowance  is  a  calculated  value  not  stored  in  the  database. 
It  is  used  on  summary  reports  only. 

■  Equivalent  processing  in  the  manual  system  w’ould  require  checking  the  trans¬ 
actions  (since  01  October  of  the  current  fiscal  year  for  NCEA)  on  the  stock 
cards  and  comparing  these  sums  against  the  NAVSEA  Ship  Allowance  and  the 
NCEA  Training  Allowance  for  each  applicable  NALC. 

■  Unlike  the  Allowance  List  Report  which  only  includes  the  allowances  and  not 
the  inventory  quantities,  this  report  assists  the  Gunnery  Officer  in  planning  the 
requisitioning  and  expenditure  of  ammunition  to  remain  close  to  100  percent 
of  Shipfill  Allowance  while  ensuring  that  ammunition  expenditures  do  not  ex¬ 
ceed  the  fiscal  year  training  allowance. 
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Volume 

■  15  per  year 
Frequency 

■  Monthly 

g.  Ammunition  Transaction  Report  (ATR) 

Output  Description 

■  A  formatted  message  containing  all  of  the  properties  shown  on  the  "Stock  His¬ 
tory"  and  "Transaction  Reporting"  sections  of  Figure  13  (except  for  Price  which 
is  only  used  for  turn-in  documents). 

Source  Data 

■  COMMAND  object  (UIC,  Name,  Service  Code) 

■  AMMO  INVENTORY  object  (NALC,  FSC,  NUN,  COG,  MCC,  ACC,  and 
Sonobuoy  Channel  [if  applicable]) 

»  TRANSACTION  object  (except  for  Price) 

■  SERIAL  and/or  LOT  CONTROLLED  AMMO  objects  (if  applicable) 

■  ATR  Addressees  and  ATR  Classification  from  the  expert  database  module  (if 
used)  or  from  user  input. 

Processing  Notes 

■  The  generated  ATR  should  be  ready  to  transmit  through  Naval  telecommuni¬ 
cations  channels. 

■  The  ATR  may  vary  in  length  from  one  transaction  (about  3  or  4  lines  on  the 
finished  report)  to  up  to  six  pages  of  transactions. 

Volume 

■  60  per  year,  within  4S  hours  of  every  transaction 
Frequency 

■  Weekly,  highly  variable 

ft.  A  TR  Log  Report 
Output  Description 

■  Report  showing  the  ATRs  sent  by  the  ship  and  containing  columns  for  ATR 
Serial  Number,  ATR  Line  Number,  Short  Title,  Quantity  Expended  /  Issued  / 
Received,  Condition  Code,  and  Quantity. 

Source  Data 

■  TRANSACTION  object  (all  instances) 

Processing  Notes 


■  Each  line  on  this  report  represents  an  instance  of  the  TRANSACTION  object 
(since  each  transaction  must  have  an  ATR  serial  and  line  number). 

•  Sorting  of  data  rows  is  by  ATR  Serial  Number  and  then  by  ATR  Line  Number. 

•  ATR  Serial  Numbers  must  be  sequentially  assigned  with  no  gaps  in  the  se¬ 
quence. 

■  In  the  manual  system,  the  ATR  Log  performs  the  function  of  this  report,  al¬ 
lowing  a  quick  reference  to  key  information  on  transaction  reports  and  serving 
as  the  source  of  ATR  Serial  Numbers. 

•  Volume 

■  30  times  per  year 

•  Frequency 

■  Biweekly 

/.  SOR  TS  Message  Input  Report 

•  Output  Description!  8 

■  Report  sent  as  a  memo  from  the  Weapons  Officer  to  the  Operations  Officer  ■ 
providing  input  for  a  message  on  combat  readiness  impact  of  ammunition  stock 
levels  (among  other  readiness  factors). 

■  Columns  for  Mission  Area  (i.e.,  ASW,  AAW,  etc.),  NALC,  Short  Title,  Quan¬ 
tity,  Shipfill  Allowance,  and  Percent  of  Allowance  Onboard. 

•  Source  Data 

-  AMMO  INVENTORY  object  (Mission,  NALC,  Short  Title,  Shipfill 
Allowance, Quantity) 

•  Processing  Notes 

■  Percentage  of  Allowance  Onboard  is  not  a  database  property  but  is  a  calculated 
value  used  for  reports. 

■  Data  rows  are  sorted  first  by  Mission  Area  and  then  by  NALC. 

■  Only  NALCs  with  Mission  Areas  assigned  are  shown  on  this  report.  (For  ex¬ 
ample,  small  arms  ammunition  and  pyrotechnics  do  not  have  assigned  combat 
mission  areas  and  would  not  appear.) 

■  Some  of  the  rows  on  this  report  could  be  duplicated,  since  it  is  recognized  that 
one  NALC  may  have  more  than  one  mission  area  (e.g.,  a  5-inch  gun  projectile 
used  for  both  ASUW  and  AMW). 

•  Volume 

■  50  per  year 

•  Frequency 


18  LT  Thomas  P.  Fortin,  L'SN  provided  valuable  input  on  the  readiness  reporting  require¬ 
ments  of  ammunition  inventory’  information. 
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.  Weekly 


j.  Ship  Ammunition  Inventory  Report  ( Summary) 

Output  Description 

■  Inventory  report  including  columns  for  GOG,  NALC,  NUN,  Short  Title,  and 
Quantity. 

Source  Data 

.  AMMO  INVENTORY  object 
-  TRANSACTION  object 
Processing  Notes 

■  This  report  presents  summary  inventory  information  and  does  not  subivide 
NALC  and  NUN  into  lots  or  serially  numbered  rounds. 

■  The  quantities  of  all  NIINs  onbuard  are  represented  on  this  report. 

■  Rows  arc  sorted  by  COG,  by  NALC,  and  then  by  NIIN. 

Volume 

■  50  per  year 
Frequency 

■  Weekly 

k.  Turn-In  Log  Report 
Output  Description 

■  Report  containing  columns  for  Document  Number,  Date,  Consignee,  Short  Ti¬ 
tle,  and  Quantity  Issued. 

Source  Data 

•  TRANSACTION  object 
.  AMMO  INVENTORY  object 
Processing  Notes 

■  This  report  summarizes  the  command's  history  of  turn-in  (ammunition  offload) 
documents. 

■  Each  Document  Number  where  an  Issue  Code  exists  is  represented  by  a  row 
on  this  report. 

■  Data  rows  are  sorted  by  Date  and  then  by  Document  Number. 

Volume 

■  Four  times  per  year 
Frequency 

»  Quarterly 


/.  Ship  Ammunition  Inventory  Report  ( Detailed) 

•  Output  Description 

»  Inventory  report  featuring  columns  for  NALC,  NIIN,  Short  Title,  Lot  Number, 
Serial  Number,  and  Quantity. 

•  Source  Data 

-  SERIAL  and/or  LOT  CONTROLLED  AMMO  object(s) 

-  AMMO  INVENTORY  object 

•  Processing  Notes 

■  This  reports  subdivides  NIINs  by  serial  and  lot  number.  It  is  more  detailed  than 
the  "Ship  Ammunition  Inventory  Report  (Summary)"  and  is  required  less  fre¬ 
quently. 

■  Data  for  the  Lot  Number  and  Serial  Number  columns  will  be  absent  for 
non-SLIT  items. 

■  The  rows  will  be  sorted  by  NALC  and  then  by  NIIN. 

•  Volume 

■  12  per  year 

•  Frequency 

■  Monthly 

m.  Outstanding  Requisition  Summary  Report 

•  Output  Description 

■  Report  on  unfilled  requisitions  consisting  of  columns  for  Document  Number, 
NIIN,  NALC,  Short  Title,  RDD,  Priority,  and  Quantity  Requisitioned. 

•  Source  Data 

•  REQUISITION  object 

■  REQN  LINE  ITEM  object 

•  Processing  Notes 

■  All  Document  Numbers  where  Requisition  Status  is  (Ujnfilled  are  sorted  first 
by  Document  Number  and  then  by  NIIN. 

■  Equivalent  action  in  the  manual  system  is  to  page  through  the  Requisition  Log 
and  find  all  entries  where  the  Requisition  Status  shows  that  the  requisition  is 
outstanding. 

•  Volume 

■  12  per  year 

•  Frequency 

■  M  onthly 

t 
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3.  Generate  Reports  Control  Mechanisms 

•  Send  output  to  screen  or  printer  at  user  option. 

•  Provide  setup  routines  where  a  printer  can  be  designated. 
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APPENDIX  F.  RELATIONAL  SCHEMA 
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Figure  16.  ARMIRS  Relation  Diagram  ( _ =key,  *  =  foreign  key) 


APPENDIX  G. 


MENU  HIERARCHY  DIAGRAMS 
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Continued  Continued  Continued  Command 

Information 
Form 
(Fig.  12) 


Figure  17,  Hierarchy  for  Main  and  Secondary’  Menus 
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Inventory  Information 
Form 

[Figure  13) 


Serlal/Lot 
Record  Form 
(Figure  14) 


Inventory 
Information 
Form  (Figure 
13) 


Figure  18.  Hierarchy  for  Menu  1  (Inventor)) 
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Figure  19.  Hierarchy  for  Menu  2  (Requisition/Turn-ln) 


Report  Output  Report  Output  Report 

Output 


Figure  20.  Hierarchy  for  Menu  3  (Generate  Reports) 
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APPENDIX  H.  LOGIC  SPECIFICATIONS 


A.  MENU  0  (MAIN  MENU) 

Until  ESC  entered: 

•  Display  ARMIRS  Main  Menu  (Figure  17) 

1.  Inventory  Management 

2.  Requisition, 'Turn-In 

3.  Reports 

4.  Ship  Information 

5.  Exit  tc  Operating  System 

•  Get  menu  choice  from  user 

•  Confirm  menu  choice 

•  Case  menu  choice 

1.  Go  to  Menu  1  (Inventory  Management,  Figure  IS) 

2.  Go  to  Menu  2  (Requisition, 'Turn-In,  Figure  19) 

3.  Go  to  Menu  3  (Report  Generation,  Figure  20) 

4.  Go  to  Menu  4  (Ship  Information,  Figure  17) 

5.  Exit  to  operating  system  prompt 

•  Else  ESC 

B.  MENU  1  (INVENTORY  MENU) 

Until  ESC  entered: 

•  Display  Menu  1 

•  Get  menu  choice  from  user  [1,2,3] 

•  Confirm  menu  choice 

•  Go  to  selected  menu  choice 

1.  Menu  1-1  (Master  Stock  Records) 

Until  ESC  entered: 

•  Display  Menu  1-1 

•  Get  menu  choice  from  user  [1,2,3] 

•  Confirm  menu  choice 

•  Go  to  selected  menu  choice 
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a.  Append  Master  Stock  Records 

•  Display  Inventory  Information  Form  (Figure  13) 

•  Get  NALC  from  user 

•  Get  FSC  from  user 

•  Get  NIIN  from  user 

•  Get  Short  Title  from  user 

•  Get  COG  from  user 

•  Get  MCC  from  user 

•  Get  Unit  of  Issue  from  user 

•  Get  Sonobouy  Channel  (optional)  from  user 

•  Get  Shipfill  Allowance  from  user 

•  Get  Mission  Allowance  from  user 

•  Get  NCEA  from  user 

•  Get  Location(s)  (optional)  from  user 

•  Get  USCG  I-lazmat  Code  from  user 

•  Get  DOT  Hazmat  Code  from  user 

•  Get  NHEEW  from  user 

•  Get  Unit  Price  from  user 

•  Get  Missions  Area(s)  (optional)  from  user 

•  Get  Low  Stock  Level  (default  =  50%)  from  user 

•  Display  confirmation  message 

•  Store  inventor}’  data 

b.  Edit  Master  Stock  Records 
Until  ESC  entered: 

•  Get  NIIN  (or  other  inventor}'  property)  from  user 

•  Display  top  part  of  Inventor}'  Information  i  orm  (Figure  13)  for  desired  stock  re¬ 
cord 

•  Get  any  (optional)  revisions  from  user 

•  Display  confirmation  message 

•  Store  revised  inventor}-  data 
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c.  Query  or  Display  Master  Stock  Records 
Repeat  until  ESC  entered: 

•  Get  NIIX  (or  other  inventory  property)  from  user 

•  Display  top  part  of  Inventor}’  Information  Form  (Figure  13)  for  desired  stock  re¬ 
cord 

2.  Menu  1-2  (Serial-Lot  Records) 

Until  ESC  entered: 

•  Display  Menu  1-2 

•  Get  menu  choice  from  user  [1,2,3] 

•  Confirm  menu  choice 

•  Go  to  selected  menu  choice 

a.  Append  Serial  and  Lot  Stock  Records 

•  Display  Serial,  Lot  Record  Form  (Figure  14) 

•  Get  NIIX  from  user 

•  If  NIIX  does  not  exist  then: 

-  Displav:"YOU  MUST  FIRST  CREATE  A  MASTER  STOCK  RECORD  FOR 
THIS  ITEM  BEFORE  CREATING  SERIAL  OR  LOT  RECORDS" 

•  Display  Short  Title  from  database 

•  Display  XALC  from  database 

•  Display  COG  from  database. 

•  Display  Remarks  from  database 

•  Get  Serial  Number  (optional)  from  user 

•  Get  Lot  Number  (optional)  from  user 

•  If  Serial  Number  exists  then: 

•  Get  Maintenance  Due  Date  from  user 
■  Get  Maintenance  Due  Type  from  user 

•  Get  Location  from  user 

•  Display  confirmation  message 

•  Store  serial  and  lot  data 

b.  Edit  Serial  and  Lot  Stock  Records 
Repeat  until  ESC  entered: 

•  Get  Serial  Number  or  Lot  Number  (or  other  property)  from  user 
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•  Display  Serial, 'Lot  Record  Form  (Figure  14)  for  desired  record 

•  Get  any  (optional)  revisions  from  user 

•  Store  revised  serial  and  lot  data 

c.  Query  or  Display  Serial  and  Lot  Stock  Records 
Until  ESC  entered: 

•  Get  Serial  Number  or  Lot  Number  (or  other  property)  from  user 

•  Display  Serial.'Lot  Record  Form  (Figure  14)  for  desired  record 

3.  Menu  1-3  (Process  Transactions) 

Unil  ESC  entered: 

•  Display  Menu  1-3 

•  Get  menu  choice  from  user  [1,2,3] 

•  Confirm  menu  choice 

•  Go  to  selected  menu  choice 

a.  Add  Transaction 
Until  ESC  entered: 

•  Get  NUN  (or  other  inventory  property)  from  user 

•  If  NI1N  does  not  exist  then: 

■  Displav:  "YOU  MUST  FIRST  CREATE  A  MASTER  STOCK  RECORD  BE¬ 
FORE  PROCESSING  TRANSACTIONS  ON  THIS  NIIN." 

•  Display  selected  Inventory  Information  Form  (Figure  13) 

•  Get  new  transaction  data  from  user 

•  If  transactions  changes  quantity  on  hand  then: 

■  Update  AMMO  INVENTORY.Quantity  on  Hand  (post  transaction  to  Master 
Stock  Record) 

•  If  Serial  Number  or  Lot  Number  exists  then: 

a  Update  quantity  in  SERIAL  and'or  LOT  CONTROLLED  AMMO 

•  If  Serial  Number  or  Lot  Number  exists  then: 

»  Update  all  (user-entered)  values  to  SERIAL  and/or  LOT  CONTROLLED 
AMMO 

b.  Delete  Transaction 
Until  ESC  entered: 

•  Get  NUN  (or  other  inventory  property)  from  user 
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•  If  NIIN  does  not  exist  then: 

•  Displav:  "NIIN  REQUESTED  FOR  TRANSACTION  DELETION  DOES 
NOT  EXIST  IN  INVENTORY.  PLEASE  TRY  AGAIN." 

•  Display  selected  Inventory  Information  Form  (Figure  13) 

•  Get  transaction  line  to  delete  from  user 

•  Update  AMMO  INVENTORY.Quantity  on  Hand 

•  Delete  (user-selected)  line  for  ATR  Serial  Number  and  ATR  Line  Number. 

•  If  Serial  Number  or  Lot  Number  exists  then: 

■  Delete  seiected  transaction  from  SERIAL  and/or  LOT  CONTROLLED 
AMMO 

•  Display  deletion  confirmation  message 

c.  Edit  Transaction 
Until  ESC  entered: 

•  Get  NIIN  (or  other  inventory  property)  from  user 

•  Display  selected  Inventor}-  Information  Form  (Figure  13) 

•  Get  any  (optional)  revisions  to  TRANSACTION  from  userl9 

•  Display  confirmation  message 

•  Store  revised  transaction  data 

C.  MENU  2  (REQUISIT  )N/TURN-IN  MENU) 

Until  ESC  entered: 

•  Display  Menu  2 

•  Get  menu  choice  from  user  [1,2, 3, 4] 

•  Confirm  menu  choice 

•  Go  to  selected  menu  choice 

1.  Append  Requisitions 

•  Display  Requisition  Information  Form  (Figure  15) 

•  Get  Document  Number  from  user 

•  If  Document  Number  exists  then: 

.  Displav:  "THIS  DOCUMENT  NUMBER  HAS  ALREADY  BEEN  AS¬ 
SIGNED.  SEE  THE  REQISITION  OR  TURN  IN-LOG  FOR  MORE  IN¬ 
FORMATION." 

19  Used  to  modify  an  unposted  transaction  only. 
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•  Get  Document  ID  from  user 

•  Get  Classification  from  v*a“ 

•  If  Classification  =  [C]  then: 

■  Get  Declass  Date  from  user 

•  Get  Remarks  from  user 

•  Get  Addressees  from  user 

•  For  each  requisitioned  item: 

■  Get  XALC  from  user 

■  Get  NUN  from  user 

»  Display  FSC  from  database 

■  Get  Quantity  from  user 

■  Get  Project  Code  from  user 

•  Get  Media  and  Status  Code  from  user 

■  Get  Signal  Code  from  user 

■  Get  Demand  code  from  user 

■  Get  Advise  Code  from  user 

■  Get  Fund  Code  from  user 

■  Get  Priority  from  user 

■  Get  Urgency  of  N *  ed  from  user 

■  Get  Required  Delivery  Date  from  user 

■  Get  Status  (optional,  default  =  [Ujnfilled)  from  user 

■  Get  Line  Classification  (default  =  [Unclassified)  from  user 

•  Display  confirmation  message 

•  Store  requisition  data 

2.  Edit  Requisitions 
Until  ESC  entered: 

•  Get  Document  Number  (or  other  requisition  property)  from  user 

•  Display  Requisition  Information  Form  (Figure  15) 

•  Get  any  (optional)  revisions  from  user 

•  Display  confirmation  message 

•  Store  revised  requisition  data 

i 
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3.  Query  or  Display  Requisitions 
Repeat  until  ESC  entered: 

•  Get  Document  Number  (or  other  requisition  property)  from  user 

•  Display  Requisition  Information  Form  (Figure  15)  for  desired  requisition  record 

4.  Menu  2-4  (Generate  Requisitions  or  Turn-Ins) 

Until  ESC  entered: 

•  Display  Menu  2-4 

•  Get  menu  choice  from  user  [1,2, 3, 4] 

•  Confirm  menu  choice 

•  Go  to  selected  menu  choice 

a.  Generate  DD  Form  1348  Requisition 
Until  ESC  entered: 

•  For  selected  Document  Number 

•  Display  "DD  FORM  1348  REQISITION  INPUT" 

■  Generate  Header  Line: 

▲  Display  Document  Identifier 

▲  Display  Media  and  Status  Code 
a  Display  FSC 

a  Display  NT  IN 
a  Display  Unit  Of  Issue 
a  Display  Requisition  Quantity 
a  Display  Service  Code 
a  Display  Document  Number 
a  Display  Fund  Code 
a  Display  COG 
a  Display  Project  Code 
a  Display  Priority 
a  Display  Required  Deliver}-  Date 
a  Display  Advice  Code 

■  Display  "A."  [UTC,  Name,  Hull  Number,  Location  for  own  ship] 

■  Display  "B."  [UTC,  Name,  Hull  Number,  Location  for  other  command] 
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-  Display  "T.  DOT  CLASS"  [DOT  Hazmat  Code]  "CG  CLASS"  [USCG  Hazmat 
Code] 

-  Display  "W."  [XALC] 

■  Display  "X."  [Short  Title] 

-  Display  "BB.  LIVE  AMMO" 

b.  Generate  DD  Form  1348  Turn-In 
Until  ESC  entered: 

•  For  selected  Document  Number  where  Issue  Code  exists: 

-  Display  "DD  FORM  1348  TURN-IN  INPUT" 

-  Display  "HEADER  LINE:" 
a  Display  FSC 

a  Display  NUN 
a  Display  Unit  of  Issue 
a  Display  Service  Code 
a  Display  Document  Number 
a  Display  COG 
a  Display  Project  Code 
a  Display  Unit  Price 

•  Display  "A."  [UIC,  Name,  Hull  Number,  Location  for  own  ship] 

•  Display  "B."  [UIC,  Name,  Hull  Number,  Location  for  other  command] 

■  Display  "E."  [Extended  Price] 

■  Display  "P."  [Material  Condition  Code] 

■  Display  "T.  DOT  CLASS"  [DOT  Hazmat  Code]  "CG  CLASS"  [USCI1  Hazmat 
Code] 

•  Display  "V."  [Lot  Number] 

•  Display  "V."  [Serial  Number] 

-  Display  "W."  [NALC] 

■  Display  "AA."  [NAR  Serial  Number] 

•  Display  "BB.  LIVE  AMMO" 

c.  Generate  DAAS  Requisition 
Until  ESC  entered: 

•  For  selected  Document  Number 

■  Display  "UNCLASSIFIED" 
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-  Display  "LMF  =  TT  CIC-ZYUW" 

■  Display  "FROM:"  [Command  Name) 

•  Display  "TO:  DAAS  DAYTON  OH" 

■  Display  "INFO:"  [Addressees] 

•  Display  "SL'BJ:  AMMO  MILSTRIP  REQN" 

■  For  each  NUN  [requisition  line): 

▲  Display  Document  Identifier 

▲  Display  Media  and  Status  Code 
a  Display  NIIN 

a  Display  Quantity 
a  Display  Document  Number 
a  Display  Demand  Code 
a  Display  Signal  Code 
a  Display  Project  Code 
a  Display  Priority 
a  Display  Required  Delivery  Date 
a  Display  Advice  Code 

d.  Generate  Naval  Message  Requisition 
Until  ESC  is  entered: 

•  For  a  selected  Document  Number: 

•  Display  "CLASSIFICATION:"  [Classification] 

■  If  Classification  =  C  then: 

a  Display  "DECLAS:"  [Declas  Date] 

■  Display  "FROM:  "[Command  Name) 

-  Display  "TO:  SPCC  MECHANICSBURG  PA" 

■  Display  "INFO:"  [Addressees] 

■  Display  [Classification]"//NO8010//" 

-  Display  "AMMO  MILSTRIP  REQUISITION" 

■  Display  "1.  ("[Classification]")" 

»  For  each  NIIN  (requisition  line): 
a  Display  [Document  Identifier]"/" 
a  Display  "NCB/" 
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▲  Display  [Media  and  Status  Code]"/" 

▲  Display  [FSC][N1IN]T 

▲  Display  [Quantity  of  Issue]"/" 

▲  Display  [Quantity]"/" 

▲  Display  [Document  Number]"/" 

▲  Display  [UIC]"/" 

▲  Display  [Signal  Code]"/" 

▲  Display  [Fund  Code]"/" 

▲  Display  [Project  Code]"/" 

▲  Display  [Priority]"/" 

a  Display  [Required  Deliver}’  Date]"/" 
a  Display  Advice  Code 

■  Display  "2.  ([Line  Classification]")"  [Remarks] 

■  Display  "DECLAS:"[Declas  Date] 

D.  MENU  3  (GENERATE  REPORTS  MENU) 

Unil  ESC  entered: 

•  Display  Menu  3 

•  Get  menu  choice  from  user  [1,2,3] 

•  Confirm  menu  choice 

•  Go  to  selected  menu  choice 

1.  Menu  3-1  (Inventory  Reports) 

Until  ESC  entered: 

•  Display  Menu  3-1 

•  Get  menu  choice  from  user  [1,2, 3, 4,5, 6, 7, 8] 

•  Confirm  menu  choice 

•  Go  to  selected  menu  choice. 

a.  Inventory  Summary  Report 
Until  ESC  entered: 

•  Display  "AMMUNITION  LISTING" 

•  Display  [today's  date] 

•  Display  "COG...NALC...NAME" 

•  For  all  NIIN  in  database  sort  by  COG  then  NIIN: 
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■  Display  COG 

•  Display  NALC 

■  Display  Short  Title 

b.  Allowance  List  Report 
Until  ESC  entered: 

•  Display  "ALLOWANCE  LIST  REPORT" 

•  Display  [today's  date) 

•  Display  "NALC...NI IN...NAME...SHI PFI LL  ALLOW...TRAINING  ALLOW." 

•  For  all  NUN  in  database  where  Shipfill  Allowance  exists  OR  where  Training  Al¬ 
lowance  exists,  sort  by  COG  then  NALC  then  NUN: 

■  Display  NALC 

•  Display  NUN 

•  Display  Short  Title 

•  Display  Shipfill  Allowance 

■  Display  Training  Allowance 

c.  NAR  Management  Report 
Until  ESC  entered: 

•  Display  "NAR  MANAGEMENT  REPORT" 

•  Display  [today's  date) 

•  Display  "NAR  #...NALC...NAME...LOT  COND.  CODE" 

•  Select  all  from  database  where  NAR  Serial  Number  exists,  sort  by  NAR  Serial 
Number: 

■  Display  NAR  Serial 
»  Display  NALC 

■  Display  Short  Title 

■  Display  Lot  Number 

•  Display  Condition  Code 

d.  Allowance  Tracking  Report 
Until  ESC  entered: 

•  Display  "ALLOWANCE  TRACKING  REPORT" 

•  Display  [today's  date] 

•  Display  "NALC... NAME.. .QTY... ALLOW.. .NCEA..NCEA  BAL..PCT  ALLOW" 
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Select  all  from  database  where  Training  Allowance  exists  OR  Shipfill  Allowance 
exists,  sort  by  NALC  then  by  Short  Title: 

■  Display  NALC 

■  Display  Short  Title 

■  Display  Quantity 

■  Display  Shipfill  Allowance 

■  Display  N'CEA  Balance 

■  Display  (Quantity, 'Shipfill  Allowance)*  100 

e.  SORTS  Message  Input  Report 
Until  ESC  entered: 

Display  (today's  date] 

Display  "FROM:  WEAPONS  OFFICER" 

Display  "TO:  OPERATIONS  OFFICER" 

Display  "SUBJ:  INPUT  FOR  SORTS  MESSAGE" 

Display  "MISSION...NALC...1TEM...QTY...ALLOW...PCT  OF  ALLOW" 

Select  all  where  Mission  Area  exists,  sort  by  Mission  Area  then  by  NALC: 

■  Display  Mission  Area 

■  Display  NALC 

■  Display  Short  Title 

■  Display  Quantity 

■  Display  Shipfill  Allowance 

■  Display  (Quantity/ Shipfill  Allowance)*  100 

/.  Ship  Ammunition  Inventory  Report  (Summary) 

Until  ESC  entered: 

Display  "SHIP  AMMUNITION  INVENTORY  REPORT  (SUMMARY)" 
Display  "(MASTER  STOCK  RECORDS  ONLY)" 

Display  [today's  date] 

Display  "COG...NALC...NIIN...ITEM...QTY" 

Select  all,  sort  by  COG  then  NALC  then  NIIN: 

■  Display  COG 

■  Display  NALC 

■  Display  NUN 


■  Display  Short  Title 

■  Display  Quantity 

g.  Ship  Ammunition  Inventory  Report  (Detailed) 

Until  ESC  entered: 

•  Display  "SHIP  AMMUNITION  INVENTORY  REPORT  (DETAILED)" 

•  Display  "(INCLUDING  LOT  AND  SERIAL  ITEMS)" 

•  Display  [today's  date] 

•  Display  "NALC.. NUN.. .ITEM. ..LOT  NR.. .SERIAL  NR...QTY" 

•  Select  all,  sort  by  NALC  then  by  NIIN: 

■  Display  NALC 
*  Display  NUN 

■  Display  Short  Title 

■  Display  Lot  Number 

■  Display  Serial  Number 

■  Display  Quantity 

h.  Maintenance  Due  Summary  Report 
Until  ESC  entered: 

•  Display  "MAINTENANCE  DUE  SUMMARY  REPORT" 

•  Display  [today's  date] 

•  Display  "NALC...ITEM... SERIAL  NR...MAINT  DUE...MAINT  TYPE" 

•  Select  all  where  Serial  Number  exists,  sort  by  NALC  then  by  Serial  Number: 

■  Display  NALC 

■  Display  Short  Title 

■  Display  Serial  Number 

■  Display  Maint  Due  Date 

■  Display  Maint  Due  Type 

2.  Menu  3-2  (Generate  Transaction  Reports) 

Until  ESC  entered: 

•  Display  Menu  3-2 

•  Get  menu  choice  from  user  [1,2] 

•  Confirm  menu  choice 

•  Go  to  selected  menu  choice  . 
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a.  Generate  AT R 


Until  ESC  entered: 

•  Display:  "CLASSIFICATION:"  [ATR  Class] 

•  If  ATR  Class  =  C  then: 

■  Display  "DECLAS:"[ATR  Declas  Date] 

•  Display  "FM:"[Command  Name] 

•  Display  "TO:  SPCC  MECHANICSBURG  PA" 

•  Display  "IXFO:"[ATR  Adressees] 

•  If  ATR  Class  =  C  then: 

-  Display  "CONFIDENTIA  L//NOS015//" 

•  Else 

•  Display  "UNCLAS//NOS015//" 

•  Display  "SUBJ:  AMMO  TRANS  RPT  RCS  SPCC  8010-12" 

•  Display  Header  Line: 

■  Display  7///[UIC]/[ATR  Serial], 7[ACC]/[Julian  Date]'//" 

•  For  each  transaction: 

•  If  Non-SLIT  (MCC  <>  C)  item: 

▲  Display  7//[NALC][NIIN]/[Condition  Code]//B[01d  Balance], '/[Transaction 
Code][Quantity];[Consignee];[Document  Number], '/[New  Balance]///" 

-  Else  (MCC  =  C): 

▲  Display"/, 7[XALC][NI IN],1 {Condition  Code]//B[01d  Balance],7[Transaction 
Code],'  [Serial  Number]  ([Maint  Due  Date]  [Maint  Due  Type])/  [Consignee] 
/[Document  Number]/  [New  Balance],'//" 

•  Display  7,7/" 

b.  A  TR  Log  Report 
Until  ESC  entered: 

•  Display  "AMMUNITION  TRANSACTION  LOG" 

•  Display  [today's  date] 

•  Display  "ATR  #  ...  ATR  LINE  ...  ITEM  ...  QTY  EXPEND  ...  QTY  ISS  ...  QTY 
RCVD  ...  COND  CODE  ...  BALANCE" 

•  Select  all  where  ATR  Serial  Number  exists,  sort  by  ATR  Serial  Number  and  then 
by  ATR  Line  Number: 

■  Display  ATR  Serial  Number 
■'  Display  ATR  Line  Number 
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■  Display  Short  Title 

■  Display  Quantity  Expended  (if  any) 

■  Display  Quantity  Issued  (if  any) 

■  Display  Quantity  Received  (if  any) 

■  Display  Condition  Code 

■  Display  Balance 

3.  Menu  3-3  (Requisition  &  Turn-In  Reports) 

Until  ESC  entered: 

•  Display  Menu  3-3 

•  Get  menu  choice  from  user  [1,2,3] 

•  Confirm  menu  choice 

•  Go  to  selected  menu  choice 

a.  Requisition  Log  Report 
Until  ESC  entered: 

•  Display  "REQUISITION  LOG  REPORT" 

•  Display  [today's  date] 

•  Display  "DOCUMENT  #...NALC...ITEM...QTY...RDD...STATUS...PRI" 

•  Select  all  Document  Numbers  where  Required  Delivery  Date  exists,  sort  by  Docu¬ 
ment  Number  and  then  oy  NUN: 

■  Display  Document  Number 

■  Display  NALC 

■  Display  Short  Title 

■  Display  Quantity 

»  Display  Required  Delivery  Date 

■  Display  Status 

•  Display  Priority 

b.  Turn-In  Log  Report 
Until  ESC  entered: 

•  Display  "TURN-IN  LOG  REPORT" 

•  Display  [today's  date] 

•  Display  "DOCUMENT  NR..DATE...TO...ITEM...QTY" 
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•  Select  all  Document  Numbers  where  Issue  Code  exists,  sort  by  Date  and  then 
Document  Number: 

■  Display  Document  Number 

■  Display  Date 

■  Display  Consignee 

■  Display  Short  Title 

■  Display  Quantity 

c.  Outstanding  Requisition  Report 
Until  ESC  entered: 

•  Display  "OUTSTANDING  REQUISITION  SUMMARY  REPORT" 

•  Display  [today's  date] 

•  Displav  "DOCUMENT  NR  ...  NALC  ...  NUN  ...  ITEM  ...  REQD  DEL  DATE  ... 
PRI  ...  QTY" 

•  Select  all  Document  Numbers  where  Requisition  Status  =  U,  sort  by  Document 
Number  then  NUN: 

■  Display  Document  Number 

■  Display  NALC 

■  Display  NUN 

■  Display  Short  Title 
-  Display  RDD 

•  Display  Priority 

■  Display  Requisition  Quantity 

E.  MENU  4  (COMMAND  INFORMATION  MENU) 

Until  ESC  entered: 

•  Display  Menu  4 

•  Get  menu  choice  from  user  [1,2] 

•  Confirm  menu  choice 

•  Go  to  selected  menu  choice 

1.  Edit  Command  Information 
Until  ESC  entered: 

•  Display  Command  Information  Form  (Figure  12) 

•  Get  LTC 

•  Get  Command  Name 
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Get  Hull  Number 
Get  Fleet 
Get  Service  Code 
Get  Location 

Get  Activity  Classification  Code 
Get  any  (optional)  revisions  from  user 
Display  confirmation  message 
Store  revised  command  data 

2.  Display  Command  Information 
Until  ESC  entered: 

Display  the  Command  Information  Form  (Figure  12) 


APPENDIX  I.  PARADOX  TABLES 
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Restructuring  M_inv  table 


STRUCT=r 

. "-T— Field  Name  ™  '  ■ 

pFielc  Type=ji 

I 

NUN 

A9* 

2 

NALC 

A4 

3 

FSC 

A4 

4 

Short  Title 

A20 

5 

COG  Symbol 

A2 

6 

Unit  Price 

$ 

7 

Sonobouy  Channel 

N 

8 

Shipfill  Allowance 

N 

9 

Warning  Level 

N 

10 

Mission  Allowance 

N 

11 

Annual  Training  Allowance 

N 

12 

Unit  of  Issue 

A2 

13 

CG  Hazmat  Class 

A4 

14 

MCC 

A1 

15 

Inv-Remarks 

A30 

16 

DOT  Hazmat  Code 

A2 

17 

NHEEW 

A10 

18 

Quantity  on  Hand 

N 

-  FIELD  TYPES  - 

A_:  Alphanumeric  (ex:  A25) 
Any  combination  of 
characters  and  spaces 
up  to  specified  width. 
Maximum  width  is  255 

N:  Numbers  with  or  without 
decimal  digits. 

$:  Currency  amounts. 

D:  Dates  in  the  form 
mm/dd/yy,  dd-roon-yy, 
or  dd.mm.yy 


Use  '**  after  field  type  to 
show  a  key  field  (ex:  A4*). 


Figure  21.  AMMO  INVENTORY  Object  Materialization 
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1 

Figure  22. 


Detail  Tables  for  INVENTORY  Master  Table 
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Restructuring  Am_miss  table 


STRUCT=jf 

■  -l  ■  a«-s3,=Field  Name*3  ■ 

-nj-Field  Type 

1 

NUN 

A9 

2 

Mission  Area 

A4 

Figure  23.  Mission  Area  Detail  Table  for  INVENTORY 
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Restructuring  Am_bal  table 


STRUCT-; 

=Field  Name—™—™ 

•Field  Type, 

1 

NUN 

A9 

2 

ATR  Serial  Number 

A3 

3 

ATR  Line  Number 

N 

4 

Document  Number 

A14 

5 

Julian  Date 

A4 

6 

Old  Balance 

N 

7 

Quantity  Issued 

N 

8 

Quantity  Received 

N 

9 

Receipt  Code 

A6 

10 

Issue  Code 

A6 

11 

Loss  Code 

A5 

12 

Extended  Price 

$ 

13 

Trng  Allow,  to  Charge 

A5 

14 

Quantity  Expended 

N 

15 

Transaction  Type 

A2 

16 

Consignee/Consignor 

A5 

17 

Balance  Serviceable 

N 

18 

Balance  Unserviceable 

N 

19 

Training  Allowance  Unexp. 

N 

20 

Quantity  Due  In 

N 

21 

Condition  Code 

A1 

22 

Revised  Condition  Code 

A1 

Restructuring  Am_bal  table 


STRUCT—! 

.  -  Field  Name  — 

?Field  Type!] 

23 

Remarks-Balchg 

A30 

24 

Referenced  ATR 

A3 

25 

NAR  Serial 

N 

26 

ATR  Class 

A1 

27 

ATR  Declas 

D 

28 

Lot  Number 

A16 

29 

Serial  Number 

A16 

Figure  24.  TRANSACTION  Detail  Table  for  INVENTORY 
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Restructuring  Am_loc  table 


Field  Name® 

NIIN 

Stowage  Location 


fField  Typesi 
A9 
A12 


Figure  25.  Stowage  Locations  Detail  Table  for  INVENTORY 
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Restructuring  Am_rln  table 

Field  Type 
A9 
N 
A3 
A1 
A1 
A1 
A2 
A2 
A1 
A3 
A1 
A1 
A2 
A14 


Figure  26.  REQN  LINE  Detail  Table  for  INVENTORY 


STRUCT^.  ■  —  iField  Name 

1  NUN 

2  Reqn  Quantity 

3  Project  Code 

4  Media  Status  Code 

5  Signal  Code 

6  Demand  Code 

7  Advice  Code 

8  Fund  Code 

9  Urgency  of  Need 

10  Required  Delivery  Date 

11  Status 

12  Line  Class 

13  Priority 

14  Document  Number 
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Restructuring  Am_lot  table 

STRUCT  ),  Field  Name - — Field  Type 

1  NUN  A9 

2  Lot  Number  A16 


Figure  27.  LOT  AMMO  Detail  Table  for  INVENTORY 
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Restructuring  Am_ser  table 


STRUCT* 

1 

j—  Field  Name-  , 

NUN 

fField  Typeii 
A9 

2 

Serial  Number 

A16 

3 

Haint.  Due  Date 

A3 

4 

Type  of  Haint.  Due  Code 

A1 

5 

Condition 

A1 

6 

1  Stowage  Location 

A12 

Figure  28.  SERIAL  AMMO  Detail  Table  for  INVENTORY 
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Restructuring  Aro_s&l  table 


STRUCT*? 

1 

- Field  Name== — 

NUN 

=Field  Type* 
A9 

2 

Serial  Number 

A16 

3 

Lot  Number 

A16 

4 

Maint.  Due  Date 

A3 

5 

Type  of  Maint.  Due  Code 

A1 

6 

Condition 

A1 

7 

Stowage  Location 

A12 

Figure  29.  SERIAL  &  LOT  AMMO  Detail  Table  for  INVENTORY 
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Restructuring  M_balchn  table 


STRUCT=j 

- Field  Name - 1 

fField  Typeii 

1 

ATR  Serial  Number 

A3* 

2 

ATR  Line  Number 

N* 

3 

Document  Number 

A14 

4 

Julian  Date 

A4 

5 

Old  Balance 

N 

6 

Quantity  Issued 

N 

7 

Quantity  Received 

N 

8 

Receipt  Code 

A6 

9 

Issue  Code 

A6 

10  ! 

Loss  Code 

A5 

11 

Extended  Price 

$ 

12 

Trng  Allow,  to  Charge 

A5 

13 

Quantity  Expended 

N 

14 

Transaction  Type 

A2 

15 

Consignee/Consignor 

A5 

16 

Balance  Serviceable 

N 

17 

Balance  Unserviceable 

N 

18 

Training  Allowance  Unexp. 

N 

19 

Quantity  Due  In 

N 

20 

Condition  Code 

A1 

21 

Revised  Condition  Code 

A1 

22 

Remarks-Balchg 

A30 

Restructuring  M_balchn  table 


STRUCT^ 

- Field  Name - . 

?Field  Type=ji 

23 

Referenced  ATR 

A3 

24 

NAR  Serial 

N 

25 

ATR  Class 

A1 

26 

ATR  Declas 

D 

30.  TRANSACTION  Object  Materialization 


Restructuring  B_aaddr  table 

STRUCT  jj  --  -  'field  Name  ■  Field  Type 

1  ATR  Serial  Number  A3 

2  ATR  Addressees  A30 


Figure  31.  ATR  Addressees  Detail  Table  for  TRANSACTION 
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Restructuring  Lot_loc  table 

STRUCT  I.  -  Field  Name  -  Field  Type 

1  Lot  Number  A16 

2  Stowage  Location  A12 


Figure  32.  Stowage  Locations  Table 


Restructuring  M_us  table 


STRUCT^ 

- Field  Name - « 

fField  Type=ji 

1 

S-UIC 

A5* 

2 

S-Name 

A30 

3 

S-Hull  Number 

A8 

4 

S-Service  Code 

A1 

5 

S-Location 

A30 

6 

S-Fleet 

A4 

7 

S-FAD 

N 

8 

S-Activity  Code 

A1 

Restructuring  M_other  table 


STRUCT=j 

- Field  Name  —  —  ■  . 

fField  Type=n 

1 

O-UIC 

A5* 

2 

0-Name 

A30 

3 

0-Hull  Number 

A8 

4 

O-Service  Code 

A1 

5 

0-Location 

A30 

6 

0-Fleet 

A4 

7 

O-FAD 

N 

8 

O-Activity  Class  Code 

A1 

Figure  33.  COMMAND  Object  Materialization 
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Figure  34.  Detail  Tables  for  COMMAND  Master  Table 


134 


'Document.  Nu»ber=^Docuinent  Identif  ier^fRegn  Class^=Reqn  Declas= 


Restructuring  Us_inv  table 


STRUCT^ 

■  Field  Name  ■  ■  . 

pField  Typeii 

1 

S-UIC 

A5 

2 

NUN 

A9 

3 

NALC 

A4 

4 

FSC 

A4 

5 

Short  Title 

A20 

6 

COG  Symbol 

A2 

7 

Unit  Price 

$ 

8 

Sonobouy  Channel 

N 

9 

Shipfill  Allowance 

N 

10 

Warning  Level 

N 

11 

Mission  Allowance 

N 

12 

Annual  Training  Allowance 

N 

13 

Unit  of  Issue 

A2 

14 

CG  Hazmat  Class 

A4 

15 

MCC 

A1 

16 

Remarks-Inv 

A30 

17 

DOT  Hazmat  Code 

A2 

18 

NHEEW 

N 

19 

Quantity  on  Hand 

N 

Figure  35.  INVENTORY  Detail  Table  for  COMMAND 


135 


Restructuring  Us_req  table 


STRUCT=j 

- Field  Name - . 

fField  Typeii 

1 

S-UIC 

A5 

2 

Document  Number 

A14 

3 

Document  Identifier 

A3 

4 

Reqn  Class 

A1 

5 

Reqn  Declas 

D 

6 

Remarks-Reqn 

A30 

7 

O-UIC 

A5 

Figure  36.  REQUISITION  Detail  Table  for  COMMAND 
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Restructuring  M_reqn  table 


STPTJ07^ 

■  Field  Name 

fField  Typeni 

i 

Document  Number 

A14* 

2 

Document  Identifier 

A3 

3 

Reqn  Class 

A1 

4 

Reqn  Declas 

D 

c: 

Remarks-Reqn 

A30 

Figure  37.  REQUISITION  Object  Materialization 


Figure  38. 
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Detail  Tables  for  REQUISITION  Master  Table 
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Restructuring  Req_adr  table 


STRUCT 

1 


=Field  Name= 


Document  Number 
Requisition  Addressees 


Field 
A14 
A30 


Figure  39.  Addressees  Detail  Table  for  REQUISITION 


Type. 


139 


Restructuring  Req2_ln  table 


STRUCT=j 

■ ' - Field  Name  . 

?Field  Type* 

1 

Document  Number 

A14 

2 

NUN 

A9 

3 

Reqn  Quantity 

N 

4 

Project  Code 

A3 

5 

Media  Status  Code 

A1 

6 

Signal  Code 

A1 

7 

Demand  Code 

A1 

8 

Advice  Code 

A2 

9 

Fund  Code 

A2 

10 

Urgency  of  Need 

A1 

11 

Required  Delivery  Date 

A3 

12 

Status 

A1 

13 

Line  Class 

A1 

14 

Priority 

A2 

Figure  40.  LINE  ITEM  Detail  Table  for  REQUISITION 
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Restructuring  M_reqnxii  table 

STRUCT  I.  Field  Name  - jfField 

1  NUN 

2  Reqn  Quantity 

3  Project  Code 

4  Media  Status  Code 

5  Signal  Code 

6  Demand  Code 

7  Advice  Code 

8  Fund  Code 

9  Urgency  of  Need 

10  I  Required  Delivery  Date 

11  Status 

12  Line  Class 

13  Priority 


Figure  41.  LINE  ITEM  Tables 


Restructuring  M_s&lam  table 


STRUCT-; 

- Field  Name - . 

rField  Typeii 

1 

Serial  Number 

A16* 

2 

Lot  Number 

A16* 

3 

Maint.  Due  Date 

A3 

4 

Type  of  Maint.  Due  Code 

A1 

5 

Condition 

A1 

6 

Stowage  Location 

A12 

Restructuring  M_seram  table 


STRUCT^ 

- Field  Name  . 

?Field  Typeii 

1 

Serial  Number 

A16* 

2 

Maint.  Due  Date 

A3 

3 

Type  of  Maint.  Due  Code 

A1 

4 

Condition 

A1 

5 

Stowage  Location 

A12 

Figure  42.  SERIAL  &  LOT  and  SERIAL  AMMO  Tables 
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APPENDIX  J.  PARADOX  DATA  VALIDITY  CHECKS 

The  following  symbols  are  used  in  used  in  the  PARADOX  "Picture"  data  masks 
below: 

•  #  =  Numeric  digit 

•  ?  =  Letter  (A-Z  or  a-z) 

•  &  =  Letter  (convert  to  uppercase) 

•  @  =  Any  character 

•  !  =  Any  character  (convert  to  uppercase) 

•  ;  =  Take  literally 

•  *  =  Repetition  counts  (any  length  allowed  by  field  type) 

•  ,  =  Alternative  values 

As  discussed  in  Chapter  V,  these  data  masks  were  adapted  from  the  ARMIRS  do¬ 
main  definitions  and  use  the  symbols  shown  above: 

•  Activity  Classification  Code:  Default  =  A,  Picture  ==  A,B,D 

•  Advice  Code:  Picture  = 

•  Annual  Training  Allowance:  Picture  =  ###§# 

•  ATR  Class:  Default  =  U,  Picture  -  U,S 

•  ATR  Line  Number:  Picture  =  ## 

•  ATR  Serial  Number:  Picture  =  #£# 

•  Balance  Serviceable:  Picture  = 

•  Balance  Unserviceable:  Picture  =  ##### 

•  CG  Hazmat  Class:  Picture  =  !!!! 

•  COG  Symbol:  Picture  = 

•  Condition:  Default  =  S,  Picture  =  S,U 

•  Condition  Code:  Default  =  A,  Picture  =  A 

•  Consignee, 'Consignor:  Picture  = 

•  Demand  Code:  Default  =  R,  Picture  =  N,R 

•  Document  Number:  Picture  =  &#$####?*###### 

•  Document  Identifier:  Picture  =  A01,A04,A0A,A0D 

•  FAD:  Min  =  1,  Max  =  5,  Picture  =  § 
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•  Fleet:  Picture  =  PAC,  LANT 

•  FSC:  Picture  =  #### 

•  Fund  Code:  Default  =  Y6,  Picture  =  Y6,  26 

•  Hull  Number:  &*! 

•  Issue  Code:  Picture  =  !!!!!! 

•  Julian  Date:  Max  =  9366,  Picture  =  ### 

•  Line  Class:  Default  =  U,  Picture  =  C,U 

•  Location:  Picture  =  &.*? 

•  Loss  Code:  Picture  =  LOSPI,LOSCE,LOSDE,LOSMD,LOSOT 

•  Maint.  Due  Date:  Picture  =  [#,&],## 

•  MCC:  Picture  =  & 

•  Media  Status  Code:  Picture  =  ! 

•  Mission  Allowance:  Picture  =  ##### 

•  Mission  Area:  Picture  =  ASW,ASUW,AAW,AMW,MIW 

•  XALC:  Picture  -  !!!! 

•  Name:  Picture  =  .*! 

•  NAR  Serial:  Picture  =  ##### 

•  NHEEW:  *! 

•  NIIN:  Picture  =  *! 

•  Old  Balance:  Picture  = 

•  Priority:  Min  =  1,  Max  =  15,  Picture  =  ## 

•  Project  Code:  Picture  =  ### 

•  Quantity  Due  In:  Picture  =  ####'# 

•  Quantity  Expended:  Picture  =  ##### 

•  Quantity  Issued:  Picture  =  #'#### 

•  Quantity  on  Hand:  Picture  =  §§§## 

•  Quantity  Received:  Picture  =  §#§§§ 

•  Receipt  Code:  Picture  =  *! 

•  Referenced  ATR:  Picture  =  ### 

•  Reqn  Class:  Default  =  U,  Picture  =  C,U 

•  Reqn  Quantity:  Picture  =  §§§#§ 

•  Required  Delivery  Date:  Min  =  001,  Max  =  366,  Picture  = 
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Requisition  Addressees:  Picture  =  *! 

Revised  Condition  Code:  Picture  =  & 

Serial  Number:  Picture  =  *! 

Service  Code:  Picture  =  ! 

Shipfill  Allowance:  Picture  -  ##### 

Short  Title:  Picture  =  *! 

Signal  Code:  Picture  =  & 

Sonobuov  Channel:  Picture  =  §# 

Status:  Default  =  U,  Picture  =  U,C,P,F 
Training  Allowance  Unexp.:  Picture  =  ####; 
Training  Allow,  to  Charge:  Picture  =  ##### 
Transaction  Type:  Picture  =  & 

Type  of  Maint.  Due  Code:  Picture  =  & 

U1C:  Picture  =  ##£## 

Unit  of  Issue:  Picture  =  && 

Urgency  of  Need:  Picture  =  A,B,C 
Warning  Level:  Picture  = 


APPENDIX  K.  PARADOX  REPORTS 


146 


148 


149 


150 


Figure  47. 
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Ammunition  Inventory  Report  (Summary) 


151 


[toqvAs  OOOc-auj  h] 


152 


153 


154 


-*pag< 


APPENDIX  L.  ATR  PREPARATION  RULE  BASE 


A.  INPUT 

1.  From  ARMIRS  Database 

•  AMMO  INVENTORY.NALC 

•  COMMAND.  Fleet 

•  COM  MAND.Hull  Number 

•  AMMUN1TION.COG 

2.  From  User  Responses  To  Queries 

a.  Multiple  Choice 

•  CHOP 

•  CHOP_From 

•  CHOP_To 

•  Deployed_To 

•  Loadout 

•  Pre_Load 

•  60_Days_Before 

•  WilTDeploy 

b.  Text  for  Addresses 

•  Ex_Wep_Prep 

•  In_Transaction 

•  Squadron 

•  Tender 

B.  OUTPUT  TO  DATABASE 

•  TRANSACTION. ATR  Class 

•  TRANSACTION. ATR  Declas 

•  TRANSACTION.Addressee  (multi-valued) 
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C.  USER  DIALOG 

1.  User  Menu  Selections 

1.  MLSF  Ships 

•  IF  COMM  AND. Hull  Number  =  A[*] 

•  THEN 

•  ASK  MLSF:  "Is  this  a  Mobile  Logistics  Fleet  ship?" 

•  CHOICES  MLSF:  Yes,  No 

2.  Complete  Onload/Ofiload 

•  ASK  Loadout:  "Was  this  transaction  a  complete  ship  onload  or  offload?" 

•  CHOICES  Loadout:  Yes,  No 

3.  Current  Deployment 

•  ASK  Deployed  JTo:  "Where  are  you  currently  deployed?" 

•  CHOICES  DeplovedJTo:  MED,  WESTPAC,  6FLT,  None  of  these,  Not  De¬ 
ployed  Now 

4.  Pre-Deployment  Period 

•  IF  DeplovedJTo  =  Not  Deployed  Now 

•  THEN 

•  ASK  60_Davs_Before:  "Will  your  ship  deploy  within  60  days?" 

•  CHOICES  60_Days_Before:  Yes,  No 

5.  Pre-Deployement  Loadout 

•  IF  60_Days_Before  =  Yes 

•  THEN 

•  ASK  Pre_Load:  "Was  this  transaction  a  pre-deployment  loadout?" 

•  CHOICES  Pre_Load:  Yes,  No 

6.  Deployment  Destination 

•  IF  60_Days_Before  =  Yes 

•  THEN 

•  ASK  Will_Deploy:  "Where  will  you  deploy  ?" 

•  CHOICES  WillJDeploy:  MED,  WESTPAC,  6FLT,  None  of  these 

7.  Changing  Operational  Commanders  (CHOP) 

•  ASK  CHOP:  "Is  this  ATR  a  CHOP  report?" 

•  CHOICES  CHOP:  Yes,  No 

8.  CHOP  Destination  and  Source 
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•  IF  CHOP  =  Yes 

•  THEN 

•  ASK  CHOP_To:  "What  is  your  CHOP  destination?" 

•  CHOICES  CHOP_To:  LANT,  PAC,  EUR,  Other 

•  AND 

•  ASK  CHOP_From:  "What  is  your  CHOP  source?" 

•  CHOICES  CHOP_From:  LANT,  PAC,  EUR,  Other 

2.  User  Text  Entry 

1.  Submarines 

•  IF  COM MAND.Hull  Number  =  SSN[*]  OR  SSBN[*] 

•  THEN 

•  ASK  Tender:  "Type  in  the  message  address  of  your  parent  or  operational  sub¬ 
marine  tender:" 

•  CHOICES  Tender:  (user-entered  text) 

2.  Exercise  Weapons 

•  ASK  Ex_Wep:  "Does  this  transaction  involve  exercise  weapons?" 

•  CHOICES  ExJWep:  Yes,  No 

•  IF  ExJWep  =  Yes 

•  THEN 

•  ASK  Ex_Wep_Prep:"Type  in  the  message  address  of  the  activity  preparing  the 
exercise  weapon:" 

•  CHOICES  Ex_Wep_Prep:  (user  entered  text) 

3.  Additional  Standard  ATR  Addressees 

•  ASK  Squadron:  "Type  in  the  message  address(es)  of  your  parent/operational 
squadron  commander:" 

•  ASK  InJTransaction:  "Type  in  the  the  message  address(es)  of  all  other  activities 
involved  in  this  transaction:" 

•  CHOICES  Squadron:  (user  entered  text) 

•  CHOICES  ^Transaction:  (user  entered  text) 

D.  RULE  BASE 

1.  ATR  Message  Security  Classification  Rules 

(1)  Submarines 

•  IF  COM -MAND.Hull  Number  =  SSN[*J  OR  SSBN[*j 
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THEN 


•  TRANS ACTI ON. ATR  Class  =  C  AND  TRANSACTION.ATR  Declas  =  today 
+  6  years 

•  [THEN  GOTO  Addressing  Rules] 

•  BECAUSE:  ATRs  submitted  by  submarines  (regardless  of  material  reported)  are 
classified  Confidential  and  are  declassified  after  six  years. 

(2)  Missiles,  Rockets,  and  Torpedoes 

•  IF  AMMUNITION.COG  =  8E  OR  4E  OR  4T  OR  8T 

•  THEN 

•  TRANSACTION.ATR  Class  =  C  AND  TRANSACTION.ATR  Declas  =  today 
+  6  years 

•  BECAUSE:  ATRs  pertaining  to  missiles  or  torpedoes  are  classified  Confidential 
and  are  declassified  after  six  years. 

( 3)  Sonobouys 

•  IF  AMMUNITION.COG  =  8U 

•  THEN 

•  TRANSACTION.ATR  Class  =  C  AND  TRANSACTION.ATR  Declas  =  today 
+  6  years 

•  BECAUSE:  ATRs  pertaining  to  sonobuoys  are  classified  Confidential  and  are  de¬ 
classified  after  six  years. 

(4)  Complete  Offloads  and  Onloads 

•  IF  Loadout  =  Yes 

•  THEN 

•  TRANSACTION.ATR  Class  =  C  AND  TRANSACTION.ATR  Declas  =  today 
+  6  years 

•  BECAUSE:  ATRs  pertaining  to  complete  onloads/offloads  may  contain  informa¬ 
tion  revealing  onboard  capabilities  of  major  weapons  systems.  They  are  classified 
Confidential  and  declassified  after  six  years. 

( 5)  Mines 

•  IF  AMMUNITION.COG  =  6T 

•  THEN 

•  TRANSACTION.ATR  Class  =  C  AND  TRANSACTION.ATR  Declas  =  today 
+  30  years 

•  BECAUSE:  ATRs  pertaining  to  mines,  destructors,  or  mine  components  are  clas¬ 
sified  Confidential  and  are  declassified  after  30  years. 
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2.  ATR  Message  Addressing  Rules 

(1 )  COMINE  IV A  RCO  A/,'  CO  MOM  A  G 

•  IF  AMMUNITION. COG  =  6T 

•  THEN 

•  [additional]  TRANSACTION. Addressee  =  COMINEWARCOM  CHARLESTON 
SC  and  COMOMAG  CHARLESTON  SC 

•  BECAUSE:  All  units  reportinc  mines,  destructors,  or  mine  components  must  info 
COMINEWARCOM  and  COMOMAG. 

(2)  CINCLANTFLT 

•  IF  (CHOP_To  =  LANT)  OR  (CHOP_From  =  LANT) 

•  THEN 

•  [additional]  TRANSACTION.Addressee  =  CINCLANTFLT  NORFOLK  VA 

•  BECAUSE:  All  units  reporting  CHOP  to  or  from  the  Atlantic  Fleet  must  info 
CINCLANTFLT. 

(3y  CINCPA  CELT:  COMNA  V LOG PAC 

•  IF  (COMMAND. Fleet  =  PAC)  OR  (CHOP  To  =  PAC  OR  CHOP_From  = 
PAC) 

•  THEN 

•  [additional]  TRANSACTION.Addressee  =  CINCPACFLT  PEARL  HARBOR 
HI  and  COMNAVLOGPAC  PEARL  HARBOR  HI 

•  BECAUSE:  All  Pacific  Fleet  units  and  other  units  upon  CHOP  to  or  from  the 
Pacific  Fleet  must  info  CINCPACFLT,  COMNAVLOGPAC. 

(4)  CINCUSNA  VEU-R 

•  IF  (COMMAND. Fleet  =  LANT  AND  Deployed_To  =  6FLT) 

•  OR  (COMMAND. Fleet  =  LANT  AND  MLSF  =  Yes  AND  60_Days  Before  = 
Yes  AND  Wi»_Deplov  =  6FLT) 

•  OR  (CHOP_To  =  EUR  OR  CHOP_From  =  EUR) 

•  THEN 

•  [additional]  TRANSACTION.Addressee  =  CINCUSNAVEUR  LONDON  UK 

•  BECAUSE:  Atlantic  Fleet  units  deployed  to  the  Sixth  Fleet,  Atlantic  Fleet  MLSF 
ships  within  60  days  prior  to  such  deployment,  and  all  units  reporting  CHOP  to 
or  from  the  European  area  must  info  CINCUSNAVEUR. 

(5)  COMNA  VAIRLANT 

•  IF  (COMMAND. Fleet  =  LANT)  AND  (AMMUNITION.COG  =  8U) 

•  THEN 
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•  [additional]  TRANSACTION. Addressee  -  COMNAVAIRLANT  NORFOLK 
VA 

•  BECAUSE:  Atlantic  Fleet  units  reporting  sonobouys  must  info 
COMNAVAIRLANT. 

(6)  COMNAVAIRPAC 

•  IF  (COMMAND.Fleet  =  PAC)  AND  (AMMUNITION.COG  =  8U) 

•  THEN 

•  [additional]  TRANSACTION. Addressee  =  COMNAVAIRPAC  SAN  DIEGO  CA 

•  BECAUSE:  Pacific  Fleet  units  reporting  sonobouys  must  info  COMNAVAIRPAC. 

(7)  Commander,  Task  Force  73 

•  IF  (COMMAND.Fleet  =  PAC)  AND  (Deploved_To  =  MED  OR  Deployed  To 
=  WESTPAC 

•  OR  (COMMAND.Fleet  =  PAC)  AND  ((MLSF  -  Yes)  OR  (COMMAND.Hull 
Number  =  CV[*]  OR  CVN[,:'])  AND  (60_Days_Before  =  Yes)) 

•  OR  (COMMAND.Fleet  =  PAC)  AND  (Pre  Load  =  Yes)  AND 
(AMMUNITION.COG  =  8E  OR  4E  OR  ST  OR  4T  OR  6T  OR  SU) 

•  THEN 

•  [additional]  TRANSACTION. Addressee  =  CTF  SEVEN  THREE 

•  BECAUSE:  Pacific  Fleet  units  deployed  to  MED/WESTPAC  and  Pacific  Fleet 
MLSF  and  aircraft  carriers  within  60  days  prior  to  deployment  in  addition  to 
Pacific  Fleet  units  reporting  predeployment  loadouts  involving  air  launched  mis¬ 
siles,  surface  launched  missiles,  torpedoes,  mines,  and  sonobuoys  must  info  CTF 
73. 

(8)  Commander,  Task  Force  63 

•  IF  (COMMAND.Fleet  =  LANT)  AND  (Deployed_To  =  MED) 

•  OR  (COMMAND.Fleet  -  LANT)  AND  ((MLSF  =  Yes)  OR  (COMMAND.Hull 
Number  -  CV(*]  OR  CVN[*])  AND  (60_Days_Before  =  Yes)) 

•  OR  (COMMAND.Fleet  =  LANT)  AND  (Pre_Load  =  Yes)  AND 
(AMMUNITION.COG  =  8E  OR  4E  OR  8T  OR  4T  OR  6T  OR  8U) 

•  THEN 

•  [additional]  TRANSACTION.Addressee  =  CTF  SIX  THREE 

•  BECAUSE:  Atlantic  Fleet  units  deployed  to  the  MED  and  Atlantic  Fleet  MLSF 
and  aircraft  carriers  within  60  days  prior  to  deployment  in  addition  to  Atlantic 
Fleet  units  reporting  predeployment  loadouts  involving  air  launched  missiles,  sur¬ 
face  launched  missiles,  torpedoes,  mines,  and  sonobuoys  must  info  CTF  63. 
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(9)  COM  FAIR  WEST  PA  C 

•  IF  (COM M  AND.Fleet  =  PAC)  AND  (AMMUNITION.COG  =  4E  OR  8E) 

•  THEN 

•  [additional]  TRANSACTION.Addressee  =  COMFAIRWESTPAC  ATSUGI  JA 
and  COMFAIRWESTPAC  DET  CUBI  PT  RP 

•  BECAUSE:  Pacific  Fleet  units  reporting  air  launched  missiles  must  info 
COMFAIRWESTPAC. 

(10)  COMP  A  CM  1STESTCEN 

•  IF  (AMMUNITION.COG  =  4E  OR  8E)  OR  (AMMO  INVENTORY.NALC  = 

<  Sea  Sparrow>  OR  <Harpoon>) 

•  THEN 

•  [additional]  TRANSACTION.Addressee  =  COMPACMISTESTCEN  POINT 
MUGU  CA 

•  BECAUSE:  All  units  reporting  air  launched  missiles,  Sea  Sparrow,  or  Harpoon  will 
info  COM  PAC  MI  STENTCEN. 

(11)  COMTHIRDFLT!  COMNA  VSURGR  V  MID  PA  C 

•  IF  (COMM AND.Fleet  =  PAC)  AND  (In_Transaction  =  NAVMAG 
LUALUALEI  HI)  AND  (AMMO  INVENTORY7NALC  =  <  5"/54  PufT>  OR 

<  5'738  Puff>) 

•  THEN 

•  [additional]  TRANSACTION.Addressee  =  COMTHIRDFLT  AND 
COMNA VSURFGRU  MIDPAC 

•  BECAUSE:  Pacific  Fleet  units  onloading  or  offloading  5"/54  or  5"/38  Puff  rounds 
from.to  Naval  Masazine  Lualualei,  HI  will  info  COMTHIRDFLT  and 
COMNA  VSURFGRU  MIDPAC. 

!  12 1  JCMPO 

•  IF  AMMO  INVENTORY.NALC  =  <Tomahawk> 

•  THEN 

•  [additonal]  TRANSACTION.Addressees  =  JCMPO  WASHINGTON  DC 

•  BECAUSE:  All  units  reporting  Tomahawk  missile  transactions  will  info  JCMPO. 

(13)  CMC  WASHINGTON  DC 

•  IF  AMMUNITION.COG  =  OT 

•  THEN 

•  [additional]  TRANSACTION.Addressee  =  CMC  WASHINGTON  DC 
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BECAUSE:  All  units  reporting  Marine  Corps-controlled  ammunition  will  info 
CMC. 


(14)  NA  VSHIPIVPNS YSENGS TA 
IF  AMMUNITION.COG  =  8E  OR  8T 
THEN 

[additional]  TRANS  ACTION.  Addressee  =  NAVSHIWPNSYSENGSTA  PORT 
HUENEME  CA 

BECAUSE:  All  units  reporting  surface  launched  missiles  and  certain  air  launched 
missiles  will  info  NAVSHIPWPNSYSENGSTA. 

(15)  PACMISTESTCEN  DELANT 

IF  (COMMAND. Fleet  =  LANT)  AND  (AMMUNITION.COG  =  8E) 

THEN 

[additional]  TRANSACTION.Addressee  =  PACMISTESTCENT  DEUANT 
YORKTOWN  VA 

BECAUSE:  Atlantic  Fleet  Units  reporting  certain  air  launched  missiles  will  info 
PACMISTESTCEN  DEUANT. 

(16)  Standard  Information  Addressees 

[additional]  TRANS  ACTION.  Addressees  =  Tender  AND  Squadron  AND 
^Transaction  AND  Ex_Wep_Prep  AND  FUTAC  CORONA  CA 

BECAUSE:  All  units  alwaysnnfo  parent  submarine  tenders,  squadron  commanders, 
commands  involved  in  the  transaction,  exercise  weapon  preparation  activity,  and 
FUTAC  Corona,  CA. 
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